HPE6-A88 ClearPass: Designing Trust at Network Access

An employee walks into a regional office, connects a laptop to Wi-Fi and can open the ticketing system but not the payroll application. A contractor plugs a camera into an Ethernet port and is restricted to the video-management service. A replacement device appears on the network but is quarantined because its certificate does not match the expected identity. Those outcomes should not depend on technicians manually moving devices between VLANs. They are the product of a network-access policy that can distinguish identity, device posture and business purpose. HPE6-A88, listed as the HPE Networking ClearPass exam in HPE's 2026 technical certification catalog, is concerned with this operational reality.

ClearPass Policy Manager is a policy decision and orchestration component in network access control, not a replacement for every switch, access point or directory. The relevant skills involve RADIUS and authentication exchanges, identity and authorization sources, enforcement profiles, profiling, guest and BYOD workflows, monitoring, and resilient operations. Current software screens can change, so a useful preparation approach follows the request from an endpoint through the network access device to a policy outcome rather than memorizing interface clicks.

Follow an access request from port to policy

A switch or wireless controller receives a connection attempt and acts as a network access server, commonly relaying an authentication conversation to ClearPass through RADIUS. The client may participate in 802.1X with EAP, or a device without a supplicant may rely on a more limited MAC-based workflow. The ClearPass service selects an authentication method, obtains identity evidence, evaluates authorization attributes and returns an enforcement decision. The exact details depend on the equipment and deployment, but the separation of responsibility is consistent: a policy server decides, while the network device applies the supported outcome.

In a troubleshooting exercise, label each participant explicitly: supplicant, authenticator, policy server, certificate authority, identity repository and endpoint. Capture the attributes in an unsuccessful access request and compare them with an authorized session. A valid password is not proof that the right enforcement profile was selected; a RADIUS accept does not prove that the switch successfully applied the intended role. Understand 802.1X authentication before changing conditions in ClearPass. The final question is what access the user actually received, not which green indicator appeared first.

Make identity sources and certificates reliable

A directory account, a client certificate and a device fingerprint answer different questions. A directory establishes identity and group membership; a certificate can bind a device or user to a trusted issuance process; profiling evidence suggests device type without necessarily proving who controls it. EAP-TLS requires attention to trust chains, validity, revocation policy and identity mapping. A certificate can be correctly signed but unsuitable because the wrong template, principal name or trust anchor was used. An endpoint could also fail because its clock is wrong, or because the intermediate certificate is missing.

Trace an EAP-TLS failure end to end. Verify the client identity, server certificate trust, selected service, authentication method and the certificate authority available to the policy server. Separate an authentication-source outage from an endpoint's refusal to trust the RADIUS server. Never resolve those issues by broadly accepting invalid certificates. ClearPass can integrate several sources, but adding more repositories is not automatically safer; inconsistent identifiers and stale directory groups make authorization less predictable. An effective design records which system owns each attribute and how changes propagate into active access decisions.

Translate business access into enforcement profiles

An enforcement policy converts evaluated conditions into a network action. Depending on the infrastructure, that might be a role, a VLAN assignment, an access-control list, a downloadable policy or a redirect to a remediation workflow. The design begins with business intent: an accounts-payable analyst may need a finance application, while a contractor needs a managed portal, and a building sensor should reach only a control service. Avoid treating VLAN numbers as the only available vocabulary. A role describes permitted activity; a VLAN is one possible implementation boundary.

Suppose a printer is allowed onto the staff network because an overly broad MAC rule matches before a more restrictive policy. A sound remediation reviews policy ordering, matching conditions and network-device capabilities rather than simply inventing another VLAN. Role mapping and enforcement selection must be verified separately: the right identity may resolve to the wrong role, or the right role may map to an obsolete network resource. Build a test table with representative device types, successful and denied operations, expected attributes and the actual enforced result. The table is a security contract, not just a certification study aid.

Treat guest, BYOD and unmanaged devices differently

Guest access usually involves a time-limited business relationship rather than full employee identity. Sponsors, registration portals, acceptable-use terms and expiring credentials support that lifecycle. Bring-your-own-device onboarding introduces a different challenge: a personal device may be trusted for a limited purpose without meeting the organization's requirements for a managed workstation. Onboarding should avoid pretending that an unmanaged phone is equivalent to a corporate laptop. Device profiling and posture checks provide useful context, but their confidence and limitations must be understood before they are used to grant privileged access.

Design three paths through a lobby network. A visitor receives internet-only service, an employee-owned phone accesses approved collaboration tools, and an unmanaged building device reaches its controller. Explain how each request is authenticated, how time limits or device changes are handled, and what happens if registration expires. In an incident, trace which identity and device attributes were relied upon. A profile that classifies hardware as a camera should not, by itself, authorize entry to security-control systems. Limit what a mistaken classification can expose and provide an auditable owner for exceptions.

Engineer the policy service for outages and change

ClearPass availability matters because access decisions occur whenever devices connect, reauthenticate or roam through infrastructure. Design nodes, clustering, licensing, DNS, NTP, backup and monitoring around the required service level. Consider the difference between a temporary RADIUS failure, a database issue, a certificate-authority outage and a network path problem to the policy nodes. Fail-open and fail-closed behavior are security decisions with availability consequences; neither is appropriate everywhere. Emergency operational access should be narrow and documented before the first outage.

Test changes in a defined sequence: update a policy in a nonproduction environment, confirm enforcement on representative wired and wireless devices, review the event logs, and then schedule production rollout with rollback instructions. A policy that succeeds on one controller model may not behave identically on an older switch software release. Track network-device credentials and shared secrets carefully. A central policy service becomes dangerous when its configuration can change across hundreds of ports without peer review or evidence of the intended impact. Reliability requires an explicit change record, not blind confidence in a centralized interface.

Use diagnostics to locate the actual denial

A user reports 'the Wi-Fi is broken', yet RF connectivity is healthy and DHCP succeeds. Access Tracker may show an accepted authentication but an unexpected enforcement rule; the controller may show a different role than ClearPass intended. Another incident has no matching request because traffic never reached the RADIUS server. These are fundamentally different fault locations. Begin by identifying whether the request exists, then inspect authentication, authorization, enforcement transmission and actual resource access in that order. RADIUS AAA exchanges provide different evidence depending on the stage that failed.

Build a lab with one successful user, one expired certificate and one misclassified endpoint. Capture both the policy-side and the network-device evidence. Check the timestamps before interpreting event order. When the user is assigned the right role but a private application still fails, follow DNS, routing and server authorization rather than continuing to modify ClearPass rules. The capability HPE6-A88 should validate is disciplined access-control engineering: being able to explain why an identity received a particular network treatment and how to correct a mistaken decision without weakening other users' protections.

A mature access-control team also rehearses loss of the monitoring pipeline. If historical authentication logs cannot be retrieved, establish whether the network device still retains a useful local record and whether a protected secondary log destination is configured. Restore event visibility before an investigation becomes an argument about what must have happened. The organization should know which changes to preserve, what can be reconstructed, and which privacy restrictions apply to authentication records. This discipline prevents an ordinary device failure from becoming a permanent evidentiary gap.

Make access governance measurable and maintainable

Mature network access control requires more than a successful initial deployment. Count unknown endpoints, stale exceptions, authentication failures, certificate-expiration events and the time needed to revoke a compromised identity. Review policy ownership and test whether employee departures are reflected promptly across authorization sources. Remove bypass rules that were created for a temporary rollout and then forgotten. A large default-allow exception is usually a sign that the organization has not resolved its endpoint inventory or onboarding process.

A useful quarterly review selects several real connection decisions and reconstructs them from source evidence: who approved access, which repository identified the user or device, which conditions matched, and what the network enforced. Include a revoked user, a newly enrolled device and a legacy device that needs controlled accommodation. Record remediation owners and dates, not just a count of passed rules. HPE network security spans the wider enforcement architecture, while ClearPass remains one important policy component. The exam-ready mindset is to measure whether access matches business authorization over time, especially as identities and devices change.