Network Access Control is an admission-and-authorization system, not just a login screen
Network Access Control (NAC) decides whether a user or device should receive normal access, restricted access, remediation access, guest access, or no access at all. The most useful AP Networking distinction is that NAC sits between basic link connectivity and ordinary network use.
Test admission and resource access as separate decisions in the AP Networking Secure Access, Authentication, and Authorization Practice Test. The questions distinguish user identity, device posture, effective segment assignment, session revocation, and the positive/negative tests needed to prove the intended boundary.
Authentication proves identity; authorization decides what that identity is allowed to do
| Stage | Question | Example outcome | What it does not prove |
|---|---|---|---|
| Authentication | Who or what is connecting? | User/device identity accepted | Which VLAN or resources are allowed |
| Authorization | What access should it receive? | Staff VLAN, guest role, printer policy | That DHCP or applications work |
| Posture | Is the endpoint compliant enough? | Normal, quarantine, remediation | That every later path succeeds |
Swipe horizontally to see the full NAC table.
802.1X separates the endpoint, the enforcement point, and the authentication backend
Supplicant
The endpoint or client software asking for network access.
Authenticator
The switch or access point controlling the port/association and relaying authentication messages.
Authentication server
Usually RADIUS or an equivalent backend that validates identity and can return authorization attributes.
Policy result
The final access role, VLAN, downloadable ACL, quarantine state, or denial.
A port can be physically up while ordinary data access remains blocked
The endpoint is physically/logically attached enough to begin admission.
Normal user data can remain restricted.
The backend evaluates credentials, certificates, identity, and policy.
Permit, deny, role/VLAN assignment, or remediation treatment.
DHCP, gateway, DNS, and application access can still fail afterward.
RADIUS logs can tell you whether the failure is identity, policy, or something after admission
Hypothetical NAC log 12:14:03 Endpoint: 7C:11:22:33:44:55 12:14:03 EAP method: certificate-based 12:14:04 Identity: student-laptop-17 12:14:04 Result: Access-Accept 12:14:04 Assigned role: STUDENT 12:14:04 Assigned VLAN: 30
This supports successful authentication and an intended authorization result. It does not prove VLAN 30 DHCP, gateway, DNS, or application paths work. If the client gets APIPA after this point, the first unresolved dependency has moved beyond NAC authentication.
NAC can authenticate users, devices, or both—and the identity source changes the failure evidence
Some deployments rely on passwords, others on device certificates, user certificates, or combinations of methods. A certificate-based failure may involve expiration, trust chain, hostname/identity mismatch, enrollment state, or policy. A password-based failure may involve bad credentials, account status, or identity source reachability.
Do not reduce every 802.1X failure to “wrong password.” The EAP method and backend log determine the right branch.
NAC can authenticate successfully and still place the endpoint into the wrong network
Authorization attributes can assign a user or device to a VLAN or role. That means two clients on the same physical switch or wireless SSID can receive different logical network treatment after authentication.
Expected policy Staff laptop → VLAN 20 Student laptop → VLAN 30 Guest device → VLAN 90 Observed Staff laptop → VLAN 90
If the staff laptop authenticates but lands in the guest VLAN, the NAC authorization policy—not the password—is the more relevant branch.
Posture checks can deliberately restrict a device that authenticated correctly
A NAC policy may evaluate operating-system version, endpoint protection status, certificate health, or other implementation-specific conditions. A device can therefore pass identity authentication and still be denied normal access because it fails posture.
Restricted access can be intentional and still look like a “network problem” to the user
A quarantined endpoint may be allowed to reach only patch servers, captive portals, antivirus update infrastructure, or remediation pages. It may be blocked from internal applications and the wider Internet. That is not necessarily a broken route; it may be the exact policy outcome NAC intended.
The correct repair is to satisfy the required posture condition or correct an erroneous policy decision—not to bypass the control with a random static address.
A guest SSID is not secure simply because it is named “Guest”
The security value comes from what the guest role can and cannot reach. A strong design commonly gives guests only the access they need, such as Internet access, while blocking internal servers and management networks.
Positive test: guest reaches the approved external service.
Negative test: guest cannot reach the internal management subnet.
That verification proves the policy outcome rather than the SSID label.
Authentication and authorization can determine whether the client ever reaches the correct DHCP scope
If the port is unauthorized, DHCP may be blocked entirely. If authentication succeeds but the client is placed in a restricted VLAN, it may receive a lease from a remediation or guest scope instead of the production scope. The IP address therefore can become evidence about authorization.
| Client state | Likely NAC interpretation | Next evidence |
|---|---|---|
| No DHCP traffic before auth | Pre-auth restrictions may be working as designed | 802.1X/RADIUS state |
| RADIUS reject, no lease | Admission denied before DHCP | Identity/EAP/certificate logs |
| Access-Accept, wrong subnet | Authorization/VLAN assignment issue plausible | Returned role/VLAN attributes |
| Access-Accept, intended VLAN, APIPA | NAC auth passed; DHCP branch unresolved | DORA, relay, scope |
Swipe horizontally to see the admission/DHCP table.
The NAC logic is similar even though the attachment mechanism differs
On wired networks, the authenticator is commonly a switch port. On enterprise Wi-Fi, the access point or wireless infrastructure enforces admission while 802.1X/EAP authenticates the client. In both cases, the important reasoning is stage-based: attachment → authentication → authorization → network services.
For wireless security-mode details, use WPA2 vs. WPA3 and Wireless Authentication Failure.
Link is up, but the user receives no DHCP lease because 802.1X authentication failed
A desktop shows Ethernet link. The switch port is configured for 802.1X. RADIUS logs show an authentication reject due to an expired certificate. The endpoint never reaches ordinary DHCP access.
Bounded diagnosis: physical link works; NAC authentication fails before DHCP. Smallest justified fix: correct the certificate/enrollment condition. Verification: Access-Accept, correct VLAN assignment, fresh DHCP lease, required application success.
Authentication succeeds, but a staff laptop is assigned to the guest VLAN
RADIUS returns Access-Accept for the user's identity, but the authorization result assigns VLAN 90 instead of VLAN 20. The laptop receives a valid guest-network IP and can reach the Internet but not internal staff applications.
The password is not the problem. Fix the role-to-VLAN authorization mapping, then verify the staff application works and guest-only destinations are no longer the endpoint's policy context.
A compliant user is quarantined because posture data is stale
The user authenticates correctly, but NAC reports the endpoint protection agent as out of compliance and places the device into remediation. Local inspection shows the agent is healthy, but the posture integration has not refreshed.
Next evidence: posture timestamp and policy evaluation reason. Correct the stale posture signal rather than weakening the access policy globally.
RADIUS accepts the client, but APIPA appears afterward
Wireless logs show successful 802.1X authentication and assignment to VLAN 30. The client then receives 169.254.44.9/16. NAC admission is no longer the first unresolved dependency.
Move to VLAN 30 DHCP evidence: Discover, relay, scope capacity, server response. Changing credentials would discard known-good evidence.
Guest Internet works, but internal management is also reachable
Guest users authenticate through a portal and receive VLAN 90 addresses. Internet access succeeds as intended, but a test reaches the switch management subnet.
The guest-access availability requirement is satisfied, but isolation is not. Apply the necessary routing/firewall/NAC restriction and verify both the allowed Internet path and the denied management path.
Use the last successful admission stage to choose the next branch
| Observation | More plausible branch | Next artifact |
|---|---|---|
| No physical link / no Wi-Fi association | Attachment/RF/link | Interface, port, radio evidence |
| Link up, 802.1X fails | Supplicant/EAP/identity/RADIUS | Authenticator + RADIUS logs |
| Access-Accept, wrong VLAN | Authorization policy | Returned role/VLAN attributes |
| Correct VLAN, no lease | DHCP/VLAN/relay/scope | DORA and scope evidence |
| Lease + gateway work, app blocked | Routing/policy/application | Firewall/ACL/service evidence |
Swipe horizontally to see the differential table.
NAC artifacts are powerful only when you state what each one does not prove
| Artifact/result | Supports | Does not prove |
|---|---|---|
| Link up | Physical/link attachment exists | NAC authorization |
| 802.1X exchange begins | Supplicant/authenticator communication starts | Authentication success |
| RADIUS Access-Accept | Backend accepted authentication/authorization request | Correct VLAN or application path unless returned attributes are checked |
| Correct dynamic VLAN | Authorization placed client in intended segment | DHCP/gateway/DNS/application |
| DHCP lease | Addressing completed in assigned network | Least-privilege policy |
| Application works | Required positive path succeeds | Prohibited paths are blocked |
Swipe horizontally to see the evidence table.
NAC is strongest when identity, role, and segmentation map to least privilege
A printer, student laptop, administrator workstation, and guest phone do not need the same access. NAC can help assign different treatment automatically, but the policy still needs a clear requirement.
Printer
Reach print servers and required management/update services only.
Student
Reach learning services without broad management access.
Administrator
Reach approved management destinations using stronger identity controls.
Guest
Internet-only or similarly limited access with internal isolation.
Not every endpoint can run an 802.1X supplicant, so fallback methods create a different trust boundary
Printers, badge readers, cameras, industrial devices, and older embedded systems may not support full 802.1X supplicant behavior. Some NAC deployments therefore use MAC Authentication Bypass (MAB) or another identity fallback. That can be operationally useful, but a MAC address is weaker identity evidence than a certificate or strong user authentication because MAC values can be copied or spoofed.
The correct AP Networking conclusion is not “MAB is always insecure.” It is that the assurance level is different. A MAB-authenticated printer should usually receive a tightly scoped role appropriate to printing, not broad employee access.
The same authenticated endpoint can receive different access depending on which policy condition matches first
NAC decisions often combine identity, device class, certificate state, group membership, posture, location, or connection type. When multiple rules could match, evaluation logic matters. A broad “employees → staff VLAN” rule evaluated before a narrower “contractor laptops → restricted role” rule can defeat the intended restriction.
Hypothetical policy order 1. IF identity-group = Employees → STAFF 2. IF device-group = Contractors → CONTRACTOR 3. IF posture = Noncompliant → REMEDIATION Contractor user is also in Employees Result: STAFF, if rule 1 wins first
This resembles firewall-rule reasoning: never inspect only the intended rule. Inspect the actual rule that matched and the resulting authorization attributes.
Access can change after initial admission when NAC reevaluates the endpoint
NAC is not always a one-time decision at connection start. A platform may reevaluate posture or identity and trigger a Change of Authorization (CoA) or equivalent action that changes the session role, VLAN, or permissions. That can explain why a client initially works and later becomes restricted without physically disconnecting.
If a user's access suddenly changes mid-session, compare the timeline of NAC policy events, posture updates, RADIUS accounting/session state, and any CoA action before assuming the switch or DHCP server randomly failed.
Time-correlated evidence is often the fastest way to prove a NAC-driven access change
Hypothetical timeline 09:00:02 802.1X authentication succeeds 09:00:03 VLAN 20 assigned 09:00:07 DHCP lease 10.20.20.54 issued 10:18:41 Posture agent reports noncompliant 10:18:42 NAC sends authorization change 10:18:44 Endpoint moved to remediation role 10:18:47 Internal application becomes unreachable
This sequence strongly supports a policy-driven access transition. The application failure occurs after a NAC state change, so changing DNS or replacing the cable would ignore the timeline evidence.
NAC dependency failure introduces an availability-versus-security design decision
If the authentication backend is unavailable, the network must decide what happens to new or reauthenticating clients. Some designs fail closed and deny access; others provide limited fallback access under carefully defined conditions. The correct choice depends on security and availability requirements.
| Design choice | Advantage | Risk | Verification question |
|---|---|---|---|
| Fail closed | Maintains strict admission control | Backend outage can block legitimate users | Does required critical access remain available through an approved contingency? |
| Restricted fallback | Preserves limited essential service | Fallback role may be too broad if poorly designed | Can fallback users reach only approved destinations? |
Swipe horizontally to see the availability/security table.
This is a classic AP Networking tradeoff: security control design must include the behavior of its dependencies when they fail.
A NAC outage can originate outside the switch even when the switch is the enforcement point
The authenticator is only one dependency. Authentication may rely on RADIUS, certificate authorities, directory services, posture servers, DNS, time synchronization, or backend databases. A switch can be healthy while admission fails because the authenticator cannot reach one of those services.
RADIUS unavailable
New 802.1X sessions may fail or enter fallback policy.
Certificate trust issue
Certificate-based authentication can fail even when credentials are otherwise valid.
Directory unreachable
User/group lookups can fail or return incomplete authorization context.
Time skew
Certificate and authentication checks can fail when system time is materially wrong.
Eight NAC statements that are too broad
- “Link up means the client has access.” NAC can block normal data after link comes up.
- “Authentication success means full network access.” Authorization and posture can still restrict the client.
- “RADIUS Access-Accept means the application should work.” VLAN, DHCP, routing, policy, and service still matter.
- “Guest SSID means guests are isolated.” Isolation must be enforced by actual policy.
- “No DHCP means DHCP is broken.” NAC may be intentionally blocking the client before DHCP.
- “Wrong VLAN means the switch port is misconfigured.” Dynamic NAC authorization can assign the wrong VLAN.
- “Posture failure means the device is definitely unsafe.” The posture signal itself may be stale or incorrect.
- “One successful application test proves secure policy.” Negative tests are needed to prove restricted access remains blocked.
Build NAC answers from stage evidence and policy outcome
Requirement: who/device should get what access?
Attachment: is link/association healthy?
Authentication evidence: supplicant, authenticator, RADIUS result.
Authorization evidence: role, VLAN, ACL/policy assignment.
Posture: compliant, quarantine, remediation, or unknown?
Boundary: what does the evidence not yet prove?
Verification: required access succeeds and prohibited access fails.
A NAC repair is complete only when identity, assigned role, network service, and restrictions all align
After repair, verify from the same type of endpoint that authentication succeeds, the correct VLAN or role is assigned, the client receives the expected IP configuration, the required application works, and protected destinations remain inaccessible where policy requires.
24 Network Access Control digital flashcards
Practice 802.1X roles, RADIUS, authentication vs. authorization, posture, quarantine, dynamic VLAN assignment, guest isolation, troubleshooting boundaries, least privilege, and positive/negative verification.