(When Authentication “Works”, but Nothing Else Does)
The most expensive NAC incidents are not Access-Reject.
They look like this:
The user authenticates successfully
Some level of access is granted
Applications fail:
SSO behaves inconsistently
From the user perspective, the network is up, but unusable.
This failure mode occurs when policy enforcement is partial:
part of the authorization result is applied, part of it is not.
1. Why These Are the Worst NAC Failures
Authentication success is a control-plane event.
Application access depends on data-plane enforcement.
Latency breaks NAC not only by denying access, but by creating a half-applied state:
ISE believes the session is authorized
The NAD enforces an outdated or incomplete policy
The endpoint sits between pre-auth and real access
This creates failures that look like application bugs, not NAC issues.
2. Typical Failure Modes (and How They Surface)
2.1 dACL / SGT Applied Late (or Never Applied)
Observed behavior:
Authentication logs show success
Endpoint remains under:
incomplete SGT enforcement
Internal applications return:
no route / blackholed traffic
Why this happens:
Authorization update is queued internally
Session ownership drift prevents enforcement
NAD never transitions the data plane
Result:
Authentication is correct, effective access is not.
2.2 CoA “Decided” but Not Enforced
A recurring pattern across posture and authorization:
ISE transitions the logical state
Live Logs show intent to send CoA
NAD never applies the update
This creates a split-brain condition:
ISE believes the session is authorized
The network enforces a different reality
This is one of the most damaging NAC bugs because:
Security teams stop investigating NAC
Application teams chase phantom outages
2.3 Session Ownership Change Breaks Reauth, CoA, and Caches
When RADIUS traffic is not persistent per session (misconfigured load balancer):
Reauth or CoA processing hits PSN-B
CoA may be rejected, ignored, or misapplied
Symptoms:
Intermittent application failures
This is often misdiagnosed as a client or application issue.
3. Internal Latency Breaks Access — Even Without Identity Stores
Latency does not need AD, LDAP, or MFA to break access.
3.1 Internal Policy Evaluation Latency
Real-world cases show:
High Authentication Latency alarms
Step latency concentrated in:
No external identity store involved
This means:
Policy resolution stalls internally
Enforcement is delayed or skipped
Access becomes unpredictable
Latency inside the PSN is just as dangerous as WAN latency.
4. Real-World Failures That Look Like “Application Issues”
4.1 DNS / Logging Impacting RADIUS → Application Failures
A documented case:
Remote logging target configured via FQDN
DNS resolution delays introduce >10s latency
Sessions flap or fall back to critical auth
User impact:
Applications intermittently fail
“The network drops” reports flood the help desk
Root cause:
AAA pipeline queueing induced by DNS/logging, not Wi-Fi or applications.
4.2 Unstable AD / DC Cascades into Application Failure
Another common pattern:
Domain Controllers alternate or flap
Step latency exceeds tens of seconds
AAA pipeline never completes cleanly
User-visible symptoms:
“The network is slow today”
The application is innocent —
the NAC pipeline never fully converged.
5. Why Latency Produces “Useless Success”
From the NAC perspective:
Authorization was computed
No explicit error occurred
From the data-plane perspective:
Policy was never fully enforced
Traffic is still restricted
This gap exists because authorization is not atomic:
Latency breaks the chain silently
6. Mitigations: Preventing “Successful but Broken” Access
6.1 Prefer Deterministic Policies
Reduce unconditional PIP lookups
Avoid policy trees with multiple equivalent outcomes
Minimize dynamic conditions applied to every endpoint
Determinism reduces partial enforcement risk.
6.2 Define “Useful Minimum Access” in Pre-Auth
If pre-auth ACLs are used, they must allow:
CRL / OCSP (if applicable)
MDM or posture portals (if applicable)
And explicitly deny everything else.
A broken pre-auth ACL guarantees broken applications.
6.3 Monitor “Time to Effective Access”, Not Just Auth Success
Authentication success ≠ usable access.
Measure:
Time from auth success to:
If enforcement takes seconds or minutes, users will notice.
Cisco performance guides clearly state:
Scale numbers assume low internal latency
AD / LDAP latency directly impacts TPS and timeouts
Small latency increases can collapse throughput
These assumptions must be explicit in the design.
Otherwise, published numbers become magic constants with no operational meaning.
7. Healthy vs Broken Enforcement (What “Working” Actually Means)
This section contrasts successful enforcement with the failure modes that produce “authentication OK, application broken”.
7.1 Healthy Enforcement Flow
Authentication and enforcement complete
dACL / SGT is applied promptly
Data-plane reflects the authorization result
Applications function immediately
This is the only definition of “success” that matters.
7.2 Broken Enforcement Flow (Partial Success)
What Users Experience
Applications fail unpredictably
No obvious failure signal
This is the most expensive NAC failure mode.
8. Why NAC Creates Application-Like Outages
From an application perspective:
DNS fails → looks like infrastructure outage
ERP times out → looks like backend issue
SMB fails → looks like AD or file server problem
From a NAC perspective:
The session is still in pre-auth or partial auth
Enforcement never converged
The data plane is enforcing the wrong policy
This disconnect makes NAC failures systemically hard to diagnose.
9. Troubleshooting Checklist
(“Auth OK, App Broken”)
Use this checklist before escalating to application teams.
9.1 Enforcement Validation (NAD)
If enforcement is wrong, stop here — this is not an application issue.
9.2 ISE Validation
If ISE thinks enforcement happened, verify ownership and CoA delivery.
9.3 Ownership and Path Validation
Ownership drift explains most intermittent cases.
9.4 Latency and Dependency Validation
Latency here produces “success without enforcement”.
10. Architectural Patterns That Prevent This Class of Failure
10.1 Treat Enforcement as a First-Class Outcome
Design goals must include:
Deterministic authorization convergence
Observable enforcement state
Authentication alone is insufficient.
10.2 Reduce Dynamic Policy Where It Adds No Value
Every additional lookup adds:
Dynamic conditions should be intentional, not habitual.
10.3 Engineer Pre-Auth as a Controlled State
Pre-auth must be:
If pre-auth is “almost usable”, failures become ambiguous and costly.
10.4 Align Scale Claims with Reality
If your environment includes:
Non-local identity stores
Then:
Scale numbers must be derated
Timeouts must be revisited
Enforcement delays must be expected and engineered
11. Cross-Module Context (Why This Keeps Happening)
This failure mode is the intersection of previous modules:
Latency delays enforcement
Ownership drift misroutes CoA
Fail-open behavior masks partial failure
Posture statefulness amplifies divergence
Application failures are often just the final symptom.
The worst NAC failures do not block access.
They pretend to grant it.
If enforcement is delayed, partial, or misapplied:
Operations chase the wrong root cause
Security believes policy is enforced when it is not
A NAC design that does not guarantee timely, observable enforcement will fail in the most expensive way possible:
Authentication succeeds.
Access does not.
And no one knows why.
