SSCP Access Controls Practice Question
A company deploys a RADIUS server for wireless 802.1X authentication. Users report that after a password change, their devices still authenticate successfully for several hours using cached credentials. Which RADIUS behavior most likely explains this?
⚠ Common exam trap
The trap here is blaming RADIUS transport or encryption for stale sessions, when the real cause is the authenticator caching an authorized state between reauthentications.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The authenticator caches the successful authentication and continues to authorize the supplicant until reauthentication is triggered
In 802.1X, the authenticator keeps a supplicant in an authorized state after a successful RADIUS exchange and only reauthenticates at defined intervals or on session events. A password change does not tear down existing authorized sessions, so devices continue to work until reauthentication is forced. Transport protocol and local authentication do not explain the observed delay.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
RADIUS encrypts only the password field and relies on a shared secret, so cached credentials are replayed
Why it's wrong here
RADIUS does obscure the password using the shared secret and a request authenticator, but this describes how credentials are protected in transit, not why stale authentication succeeds. The cached-credential behavior is about the authenticator reusing a prior successful result, not about password field encryption. While the shared secret is important for integrity, it does not cause a device to keep authenticating with an old password after a change.
- ✓
The authenticator caches the successful authentication and continues to authorize the supplicant until reauthentication is triggered
Why this is correct
In 802.1X, the authenticator can maintain an authorized state for a supplicant after a successful RADIUS exchange and only reauthenticate at a configured interval or on a session event. Until reauthentication occurs, the device remains authorized even though the password changed. This caching of authorization state, governed by session and reauthentication timers, is the most likely reason users keep working for hours after the change.
- ✗
RADIUS uses UDP and therefore cannot immediately propagate a password change to the client
Why it's wrong here
RADIUS commonly uses UDP, but the transport protocol is not the cause of stale authorization. The delay comes from the authenticator holding an authorized session rather than from UDP's connectionless nature. Even over TCP, an established authorized session would persist until reauthentication. The transport choice affects reliability and retransmission behavior, not the lifetime of an already-authorized 802.1X session, so this explanation is incorrect.
- ✗
The wireless controller performs local authentication and never contacts the RADIUS server
Why it's wrong here
If the controller never contacted RADIUS, initial authentication would fail unless local accounts existed. The scenario states users authenticate successfully, implying RADIUS is involved. The issue is not that the server is bypassed but that an already-authorized session persists. Local authentication would also not explain why the problem appears specifically after a password change, so this option misidentifies the mechanism.
Quick reference
AAA Protocol Comparison
| Protocol | Port(s) | Encryption | Transport | Primary Use |
|---|---|---|---|---|
| RADIUS | 1812 / 1813 | Password only | UDP | Network access control |
| TACACS+ | 49 | Full packet | TCP | Device administration |
| Diameter | 3868 | Full session | TCP / SCTP | Carrier / mobile networks |
| 802.1X | — | EAP-based | Layer 2 | Port-based access control |
TACACS+ encrypts the entire packet; RADIUS only encrypts the password field — a key exam distinction.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SSCP question from scratch — 971 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISC2 exam blueprint
This SSCP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SSCP exam.