AAA Design
Authentication, authorization, and accounting (AAA) provide the foundational mechanisms for controlling network access and enforcing the permissions assigned to connected users and devices.
Before a device can access the network, it must be identified. This requires that device information is either pre-registered in a directory or database, or discovered and profiled at the time of connection. When a client attempts to connect, the NAC solution retrieves the relevant user and device attributes, evaluates them against defined policy, and returns an allow or deny decision to the network infrastructure.
Upon succesful authentication, the NAC solution assigns the priviledges associated with the clients, including the resources available to the clients, the conditions for maintaining access and the enforcement point for policy within the network.
Beyond initial onboarding, the network must continuously monitor connected clients. If a device exhibits anomalous behavior or is determined to be compromised, the NAC solution must be able to respond dynamically by restricting or revoking access without requiring manual intervention.
Client onboarding does not follow a single model. Guest users, BYOD devices, and IoT endpoints each introduce unique requirements. A well-designed Zero Trust architecture addresses these differences by selecting authentication mechanisms that preserve security, support efficient access, and reduce unnecessary friction for legitimate users while limiting opportunities for misuse.
This chapter covers the design considerations for each of these areas across both on-premises and cloud NAC deployments.
Table of contents
AAA Overview
This section describes the technical contructs to be considered during authentication design
Authentication
Authentication is the process of validating the identity of a user or device. This chapter describes the mechanisms used to perform authentication and authorization in the enterprise network and outlines the design of the systems that support these functions. The appropriate authentication method for a given client depends on three prerequisites that must be evaluated before defining the authentication design.
Client type and supplicant capability: Not all devices support the same authentication mechanisms. Corporate-managed laptops and mobile devices typically support a full 802.1X supplicant, while IoT endpoints and legacy devices often do not. The authentication method must match what the device can support without assuming a capability that is absent.
Certificate infrastructure: Certificate-based authentication methods require a functioning PKI including a certificate authority, a distribution mechanism, and a renewal process. Before selecting an authentication method that depends on certificates, confirm that the PKI is in place or that the project scope includes its deployment.
Identity store: The NAC solution must be able to validate credentials or attributes against an authoritative source. The choice of identity store between Active Directory, LDAP, a cloud identity provider, or a local database directly constrains which authentication methods are viable and must be confirmed before the authentication design is finalized.
Authorization
Authorization is the process of determining the actions and network access permitted to an authenticated user or device. It defines the resources available to the client, the network segment or role assigned to the client, and the policies applied to the client’s traffic. Authentication concludes when the NAC solution validates the client’s credentials or attributes against the identity source. In RADIUS-based workflows, authorization is conveyed through the attributes returned in the Access-Accept message.
Authorization attributes instruct the network infrastructure on client placement and traffic treatment. In HPE Aruba Networking deployments, the Aruba-User-Role Vendor-Specific Attribute (VSA) is the primary authorization construct. The role is resolved locally on the switch, access point, or gateway into a predefined set of policies that govern segmentation, firewall rules, bandwidth, and forwarding behavior. Because the role travels with the client across wired and wireless infrastructure, a single role definition drives consistent enforcement regardless of the client’s connection point.
VLAN assignment remains a valid authorization construct and is carried in the standard RADIUS attributes. VLAN assignment is appropriate for macro segmentation use cases, such as isolating guest traffic or separating IoT device classes into dedicated subnets. In a NetConductor fabric, VLAN assignment maps to an overlay segment. In a traditional campus, it places the client in a locally configured VLAN. Role and VLAN assignment are not mutually exclusive and are often used together, with the VLAN providing the macro segment and the role providing micro segmentation within it.
Additional RADIUS attributes can be returned to shape session behavior, including Filter-Id for referencing preconfigured ACLs, and vendor-specific attributes for bandwidth contracts or captive portal redirection.
Accounting
Once the client has been authenticated and assigned a role and VLAN, RADIUS accounting provides session visibility that supports both auditing and dynamic enforcement. RADIUS accounting records session start, interim update and stop events for authenticated client sessions. These records typically include identifiers such as the user or client identity, NAS identifier, accounting session ID, session duration, and assigned IP address. The resulting data supports trend analysis, capacity planning, auditing, and, in some environments, billing or cost reporting.
Interim accounting updates should be configured so that session state remains current between start and stop events. The update interval should align with audit requirements and deployment scale. Accounting records also provide the session context commonly used for Change of Authorization (CoA) enforcement. The NAC solution must maintain an active entry session to map an enforcement action back to a specific NAD and session ID. The CoA is sent from the NAC platform to the NAS. For wired clients, the switch serves as the NAS. For tunneled wireless clients in AOS 10 deployments, the gateway serves as the CoA target.
For example, in a ClearPass deployment, a client can initially authenticate with an Employee role, after which the NAS begins sending RADIUS accounting records to ClearPass and an active session is established. If endpoint profiling subsequently classifies the device into a category associated with a different enforcement outcome, ClearPass can use a configured CoA profile to modify the active session. In Aruba environments, this action can include sending an updated Aruba-User-Role value, such as changing the client role from Employee to Guest. The NAS acknowledges the CoA request and applies the updated authorization attributes to the active session.
Authentication Sources
Authentication sources are identity repositories used to validate client credentials and when applicable, retrieve authorization attributes. In campus deployments, these typically include on-premises directories such as Active Directory, cloud identity providers such as Microsoft Entra ID, Okta Workforce Identity, and Google Workspace, local databases on the NAC solution itself, and the certificate authorities that underpin certificate-based authentication. Cloud identity providers communicate with NAC using REST APIs and traditional on-premise directories use LDAP to communicate with NAC solutions.
Authentication source selection should begin with alignment between the NAC platform and the identity systems in scope. Central NAC integrates with cloud identity providers such as Microsoft Entra ID, Okta Workforce Identity Cloud, and Google Workspace for authentication and authorization. ClearPass supports Active Directory, LDAP-compliant directories, and other external authentication sources, and it can perform certificate-based authentication while retrieving authorization attributes for policy decisions. Organizations that standardize on cloud identity providers can align well with Central NAC, while environments that rely on Active Directory or LDAP often align well with ClearPass. Hybrid environments are common, and the selected NAC platform should support the combination of identity and certificate services required by the design.
The second consideration is the mapping of authentication sources to client types. Corporate devices using EAP-TLS rely on the certificate authority as the trust anchor, with the identity store consulted for user or machine attributes that feed authorization. BYOD and contractor devices often authenticate against a dedicated identity store or a scoped group within the primary directory to keep their credentials and attributes separate from corporate accounts. IoT devices authenticated via MAB depend on the local NAC database or an endpoint repository populated by profiling, and guest devices authenticate against a guest account database managed within the NAC solution. Each client category drives a different source combination, and the design must document the authoritative source for each flow.
The third consideration is operational, covering connectivity, resiliency, and lifecycle. Every authentication source introduces a dependency that must be reachable from the NAC solution at the time of authentication, and the design must account for the failure mode of each. Cloud identity providers require outbound internet reachability and introduce a dependency on the provider’s availability, which should be factored into site survivability planning. Certificate authorities require a functioning revocation-checking mechanism, whether OCSP or CRL, and the NAC solution must be configured to handle revocation check failures in a manner consistent with the organization’s security posture. Credential and certificate lifecycle processes, including joiner-mover-leaver workflows in the directory and certificate renewal in the PKI, must be operational before the authentication design can be considered complete.
Device Context Sources
Authentication sources confirm the credentials presented by the user or device. They do not, by themselves, describe the state of the endpoint. Identity sources fill this gap by providing device-centric attributes that the NAC solution can use during authorization to refine role assignment. These attributes are evaluated alongside the authenticated identity to produce a role assignment that reflects both the client identity and the current posture of the endpoint..
Mobile Device Management (MDM) and Unified Endpoint Management (UEM) platforms are common sources of device context. These platforms maintain records related to device enrollment, compliance, ownership, and management state, which can be consumed by the NAC platform during authorization. For example, a corporate laptop can authenticate to the network using EAP-TLS with a certificate issued by the organization’s PKI. After successful authentication, the NAC platform can use an identifier established during onboarding to retrieve the corresponding device record from Microsoft Intune. If the device is enrolled and compliant, the NAC platform can assign a corporate access role. If the device is enrolled but non-compliant, the NAC platform can instead assign a restricted role that limits access to remediation, patching, or management services until compliance is restored.
Unified Endpoint Management (UEM) platforms provide a centralized platform for managing and securing corporate and BYOD endpoints across operating systems such as Windows, macOS, iOS, Android, and Linux. Common UEM platforms include Microsoft Intune, VMware Workspace ONE, Jamf, and Ivanti Neurons. The NAC solution uses a device identifier, typically the certificate subject, username, or MAC address, to look up the corresponding device record in the UEM. The lookup occurs during authorization, after the client has successfully authenticated.
For a UEM-based integration to function correctly, the device must be enrolled in the UEM platform before it connects to the network. Onboarding workflows for new devices must account for the sequence in which enrollment and network access occur. For corporate devices, enrollment typically happens during provisioning before the device is issued to the user. For BYOD devices, the onboarding workflow must guide the user through UEM enrollment before granting full network access, often using a restricted provisioning role during the enrollment phase. Finally the device must check in with the UEM on a regular cadence so that compliance attributes remain current.
Client Authentication Design
With these prerequisites established, the sections below address the authentication and authorization design for each client category present in a campus environment.
Corporate Devices
Corporate devices are endpoints that are owned, provisioned, and managed by the organization. Because the organization controls the full lifecycle of these devices, from procurement through retirement, it can enforce a consistent configuration, distribute certificates via MDM or GPO, and mandate supplicant settings. This degree of control makes corporate devices well suited for 802.1X authentication. 802.1X is the recommended authentication method for corporate devices. It provides a cryptographically strong mechanism for authenticating both the device and, where required, the user before network access is granted. The specific EAP method used within 802.1X depends on the PKI posture of the organization.
Where a PKI is available, EAP-TLS is the preferred method. The device presents a machine certificate issued by the organization’s CA during the TLS handshake, providing mutual authentication between the device and the NAC solution. Because authentication is certificate-based, it does not depend on a user being logged in. The device authenticates to the network at boot, independent of user credentials. This is important for ensuring that domain policies, software updates, and management traffic reach the device before a user session begins.
Where a PKI is not yet available, PEAP-MSCHAPv2 is the common alternative. The device authenticates using user or machine credentials validated against Active Directory. While easier to deploy, this method is more susceptible to credential-based attacks if supplicant profiles do not enforce server certificate validation. Organizations using PEAP-MSCHAPv2 should treat it as a transitional posture and plan a migration to EAP-TLS as PKI maturity increases. With access to PKI, TEAP is another alternative to EAP-TLS and its advantage over EAP-TLS is the support for EAP chaining, allowing the machine and the user to be authenticated in a single EAP session. TEAP adoption is constrained by supplicant support and needs to be validated before implementing in a campus network.
In both cases, the NAC solution evaluates the authentication result and returns an Aruba User Role and/or a VLAN assignment to the network infrastructure, placing the device in the appropriate network segment with the correct access policy applied. Role resolution typically incorporates group membership from the identity’s store, and may include device posture, client OS, or time of day as additional inputs. Integration with a Unified Endpoint Management (UEM) platform such as Microsoft Intune allows device compliance and enrollment attributes to be consumed as additional inputs to the role decision.
BYOD Devices
BYOD refers to personally owned devices that employees use to access corporate resources. Unlike corporate devices, the organization does not control the hardware procurement or base configuration of these endpoints, which introduces complexity into the authentication design.
The recommended approach is to authenticate BYOD devices using 802.1X with EAP-TLS, with the client certificate provisioned through a self-service onboarding workflow. The employee connects to a designated onboarding SSID or wired port, authenticates using their corporate credentials, and the NAC solution provisions a short-lived client certificate to the device. On subsequent connections, the device presents this certificate for authentication and is assigned a BYOD-specific role with access scoped to the resources the organization has approved for personal devices.
The BYOD onboarding workflow requires a dedicated network path that provides enough connectivity for the device to complete enrollment without granting access to production resources. This is implemented as a restricted onboarding SSID or a wired VLAN with a role that permits only the traffic required for enrollment: DNS, DHCP, and connectivity to the NAC solution and any external services required for certificate provisioning. When a BYOD device initiates enrollment, the NAC solution first validates the employee’s corporate credentials against the configured identity store. If credential validation succeeds, the NAC solution creates a device record associating the device with the authenticated user and then generates and issues a client certificate to the device, with the certificate subject tied to the authenticated user identity or the device record. Alongside certificate issuance, the NAC solution provisions the supplicant configuration on the device to use EAP-TLS for subsequent connections. The device is held in the onboarding role until enrollment completes, at which point it transitions to the BYOD role.
A key design consideration for BYOD is the organization’s policy on data sovereignty and device management. When a personal device is enrolled in an MDM solution as part of the onboarding process, the organization gains the ability to enforce configuration baselines and, critically, to remotely wipe corporate data from the device in the event of loss, theft, or a security breach. This capability must be clearly communicated to employees as part of the onboarding process, and the scope of any remote wipe action must be defined in the organization’s acceptable use policy before enrollment is offered.
BYOD devices should be assigned a role that is distinct from corporate-managed devices, even when the same user is authenticated. The role assigned to a BYOD device should reflect a more restrictive access profile, limiting connectivity to approved applications and services rather than providing broad internal access.
Contractor Devices
Contractor devices are endpoints that are owned and managed by a third party either by the contractor personally or by their employer and brought into the campus environment to perform a defined scope of work. The organization has limited or no control over the configuration, patch level, or security posture of these devices.
The authentication design for contractor devices must account for this variability. In environments where the organization issues contractors a certificate through a controlled onboarding process, 802.1X with EAP-TLS is viable and provides strong authentication. Where this is not practical, PEAP-MSCHAPv2 against a contractor-specific account in the identity store. The account should be created in a dedicated organizational unit separate from employee accounts. This separation simplifies account lifecycle management and reduces the risk of contractor accounts inheriting permissions intended for employees. Where supported by the NAC platform, contractor authentication can also be integrated with external identity sources managed by the contracting agency or another trusted third party.
Regardless of the authentication method used, contractor devices should be assigned a role that strictly limits access to the systems and services relevant to their engagement. Contractor roles should not provide broad internal access, and access duration should be enforced through account expiry or time-based policy conditions in the NAC solution. The access profile for contractor devices should be reviewed and confirmed with the business owner of the engagement before the role is defined in the policy manager.
IoT Devices
IoT devices including IP cameras, badge readers, HVAC controllers, building management sensors, and similar endpoints, present a fundamentally different authentication challenge from user-facing devices. These devices typically run embedded firmware with no support for an 802.1X supplicant, no user interaction model, and no mechanism for certificate provisioning. As a result, 802.1X is not a viable authentication method for the majority of IoT endpoints.
MAC Authentication Bypass (MAB) is the standard authentication method for IoT devices. The device’s MAC address is submitted to the NAC solution as the authenticating credential. The NAC solution looks up the MAC address in a device registry and, if a match is found, returns a role assignment to the network infrastructure. For wireless IoT deployments, Multi Pre Shared Key (MPSK) is an alternative to MAB that provides per device authentication without requiring supplicant support. Rather than submitting a MAC address as the authentication credential, each IoT device is provisioned with a unique pre shared key that the NAC solution maps to a specific role and network segment. MPSK is particularly useful for environments where MAC address management is operationally difficult.
Consider a wireless IP camera as a representative example. The camera connects to a dedicated IoT SSID, and its MAC address is submitted to the NAC solution via MAB. The NAC solution matches the MAC address against a registered entry in its device database, identifies the device as a camera, and returns a role that permits outbound traffic only to the video management server on a specific port — blocking all other connectivity. The camera is placed in an isolated network segment, limiting the blast radius if the device is compromised.
A critical weakness of MAB is that MAC addresses can be spoofed. To mitigate this, MAB should always be paired with device profiling. The NAC solution uses DHCP fingerprinting, HTTP User-Agent strings, and infrastructure telemetry to classify the device type independently of its MAC address. HPE Aruba Networking Central includes AI powered Client Insights, which uses native telemetry from access points, switches and gateways to classify connected devices based on the observed traffic behavior, communication patters, and endpoint characteristics. If a device that authenticated successfully begins exhibiting behavior inconsistent with its classified type, Client Insights can surface that anomaly and, when paired with Central NAC, trigger a dynamic Change of Authorization to restrict or quarantine the device without waiting for a scheduled re-authentication. Based on the visibility and profiling, client tags can be associated to the clients and then enforce policy based on the tags. This closed loop between profiling, visibility, and enforcement is the primary mechanism for containing compromised IoT devices after they have been admitted to the network.
Guest Devices
Guest users are individuals who require temporary network access but have no pre-existing identity in the organization’s directory such as visitors, partners or event attendees. For low friction guest wireless access, an Open guest SSID with Opportunistic Wireless Encryption (OWE) is a strong design option. A traditional open SSID does not provide data encryption on the air. OWE preserves unauthenticated association while adding per-session encryption between the client and the access point. Each guest client derives a unique pairwise key during association, which protects traffic from passive eavesdropping without requiring credentials, certificates, or captive portal interaction.
When OWE is not supported by the guest device population or where the organization requires credential-based access control at the guest boundary, a web-based portal is the fallback approach. When a guest device connects to the guest SSID, it is redirected to a registration or login page hosted by the NAC solution. The guest provides identifying information which the NAC solution records and uses to generate a time-limited access credential.
Once authenticated, the guest is assigned a role that restricts connectivity to internet access and any shared services the organization has explicitly approved for guest use, such as DNS and DHCP. Access to internal resources, file shares, and management networks must be explicitly denied in the guest role policy. Access duration should be enforced at the NAC solution level, with automatic session termination at expiry rather than relying on the guest to disconnect.