Before you read. A contractor finished in March. In September somebody notices their account still logs in, and has done all year.
Nobody did anything wrong. There was a leavers process, it was followed, and the account was on none of the lists it needed to be on.
Where does an account like that come from, and what would have caught it?
Access management is where security stops being technical. Every mechanism in this topic works. What fails is the join between the mechanism and the organisation, and that join is a process rather than a protocol.
Some words you will need
- authentication
- Establishing who somebody is.
- authorisation
- Deciding what they may do, once you know who they are.
- factor
- A category of evidence: something you know, something you have, something you are.
- single sign-on
- Authenticating once and being accepted by several systems on the strength of it.
- least privilege
- Granting the access the job needs and no more.
- role-based access control
- Granting access to a role and putting people in roles, rather than granting to people.
- geofencing
- Allowing or refusing based on where the request appears to come from.
What breaks without this
Accounts outlive the people. Every organisation has some, and they are the most useful thing an attacker can find, because they are legitimate.
A refused action gets investigated as a break-in. Authentication and authorisation fail differently, and a log that conflates them sends people looking for the wrong thing.
Second factors get added that are not factors. A second thing you know is not a second factor, and a control that feels stronger without being stronger is worse than none, because it stops the conversation.
Two questions, not one
The two words get used together so often that they blur, and separating them is the most useful thing on this page.
Authentication is who are you. It is answered once, at the start, and the answer is a claim backed by evidence.
Authorisation is what may you do. It is answered continuously, for every action, and the answer can be no for somebody perfectly legitimate.
The exam adds accounting, which is recording what they did. The three together are the reason the servers in the last section are called AAA servers.
If you already run access reviews: why the second question is the one that decays
Authentication is a solved problem in most organisations and authorisation is where the mess accumulates, for a structural reason rather than a lazy one.
Authentication is evaluated fresh every time, so it cannot drift: a departed employee’s login stops working the moment the account is disabled, and that failure is loud and immediate. Authorisation is a set of grants that persist, and nothing about a grant announces that it is no longer needed. Somebody moves from one team to another, gains the access the new role requires, and keeps what the old one gave them, because removing it is a separate act nobody is prompted to perform.
The result is that permissions only ever accumulate, and the people with the most access are frequently the people who have been there longest rather than the people whose current job needs it. That is invisible day to day and becomes the whole story the moment one of those accounts is compromised.
Which is why an access review is a scheduled activity rather than a reaction, and why reviewing by role rather than by person is the version that finishes. Asking whether a person should still have forty grants is a conversation nobody can complete. Asking whether the role they now hold should carry a particular grant is answerable, and the people attached to that role follow from it.
Factors, and what makes one
Multifactor authentication means evidence from more than one category, and the categories are what the word factor refers to.
Something you know is a password or a PIN. Something you have is a phone, a token, a card. Something you are is a fingerprint or a face.
Two things from the same category are not two factors. A password and a security question are both things you know, and somebody who has phished one has usually phished the other. That is not a pedantic distinction; it is the entire content of the word.
NIST SP 800-63B is the free document here and it is unusually opinionated for a standard. It is worth knowing about because it says things the industry took a decade to accept, including that forcing regular password changes makes passwords worse rather than better.
Time-based one-time passwords are the common second factor: a code that changes every thirty seconds, generated from a shared seed and the clock. Worth noticing what that depends on, because it explains the failure. Both ends need the same time, so a device whose clock has drifted produces codes that are correct and rejected, and topic 48 is about the protocol that stops that happening.
If you already run multifactor: why the categories matter less than how the second factor is delivered
The category rule is the exam’s answer and it stops short of the distinction that decides whether a deployment actually helps.
Two things in the have category can be very different. A code sent by text message is something you have in the sense that it arrives on your phone, and it can be intercepted by anybody who persuades a network operator to move the number, which is a routine attack rather than a theoretical one. A code from an application on the device is better and can still be read out by a user who has been telephoned by somebody convincing. A hardware key that signs a challenge tied to the site’s name cannot be read out at all, because there is nothing to read and it refuses to sign for the wrong name.
That last property is the one worth understanding, because it defeats the attack that defeats everything else. A user tricked into visiting a convincing copy of a login page will type a password and will relay a code, and the copy passes both along in real time. A key that checks which site it is talking to declines, and the user cannot override it by being persuaded.
So the useful ranking is not by category but by whether the factor can be relayed by a person who has been fooled. Anything a user can read and retype can be relayed. Anything cryptographically bound to the site cannot. Most deployments that were rolled out years ago sit at the readable end, which is much better than nothing and is not what people assume they bought.
The four services, and the one distinction worth memorising
The exam names four and they are easy to confuse because they overlap.
RADIUS authenticates users for network access. It is what the enterprise wireless in topic 32 talks to, and what a switch running 802.1X talks to.
TACACS+ does the same job for administrative access to devices, and separates authentication from authorisation properly, so it can decide per command rather than per session.
LDAP is a directory protocol. It is where the accounts live, and the others frequently consult it rather than replacing it.
SAML federates. It lets one organisation’s identity be accepted by another’s application, which is what makes single sign-on work across companies. It is not a login protocol in the sense the others are, and the exam’s phrasing invites that confusion.
Least privilege, and why roles
Least privilege is granting what the job needs and nothing else. Everybody agrees with it and almost nobody implements it, and the reason is that it is easier to grant than to work out what is needed.
Role-based access control is the mechanism that makes it survivable. Instead of granting access to Sam, you define a role, grant access to the role, and put Sam in it. That sounds like an extra step and it buys three things.
Somebody joining gets a role rather than a copy of whoever sits nearest, which is how privilege accumulates. Somebody changing jobs changes role, and the old access goes with it rather than accreting. And the question what can this person do becomes answerable by reading one role rather than auditing every system.
Geofencing is a coarser control: allowing or refusing based on where a request appears to come from. It is genuinely useful as a signal and it is trivially defeated by anybody who cares, so its place is raising suspicion rather than making decisions.
The account that outlived the job
Now the contractor.
Accounts like that come from the gap between the systems that know somebody left and the systems that grant access. A leavers process starts in the system that knows about employment, and a contractor is frequently not in that system: they are in a purchase order, or in somebody’s calendar, or in an email thread.
So the account was never on the list because the person was never on the list. The process worked correctly on the population it knew about.
Three things catch this, and only one of them is technical.
Accounts that expire by default. A contractor account created with an end date closes itself, and renewing it is a deliberate act by somebody who currently wants it open. This is the single most effective control here and it costs nothing.
Access review. Somebody who knows the team reads the list of who has access and says which names they do not recognise. It is dull, it is periodic, and it is the only thing that catches accounts nobody has a record of.
Joining the sources. If accounts can only be created from a system of record that includes contractors, the gap closes at the origin. That is a bigger change and it is the one that actually fixes it.
If you already work on networks: why single sign-on makes this better and worse at the same time
Single sign-on is usually sold on convenience, and its real value is the one in this topic: it collapses many accounts into one, so disabling that one disables access to everything joined to it.
An organisation with forty separate systems has forty leavers problems. One with single sign-on has one. That is a genuine and large improvement in exactly the failure this page is about.
The cost is that it collapses the blast radius the same way. One credential now opens forty systems, which raises the value of stealing it by a factor of forty, and this is precisely why the second factor moves from a nice idea to a requirement. An organisation that deploys single sign-on without multifactor has concentrated its risk and not defended it.
Two more consequences that turn up in practice.
Something has to remain that is not behind the single sign-on, because when the identity provider is unreachable, somebody has to be able to fix it. That account is by definition outside the mechanism protecting everything else, and it needs its own protection and its own audit. Organisations either forget it exists or protect it properly, and the second is rare.
And a joined system does not necessarily stop trusting an existing session when the account is disabled. Disabling somebody centrally stops new logins immediately, and an application holding a session token may keep working until it expires. The gap is usually minutes and occasionally hours, and it is worth knowing before somebody assumes the disable was instantaneous.
Prove it
There is no capture on this page and the reason is worth being straight about. Demonstrating the RADIUS and TACACS+ difference properly needs a working server of each and a capture between them, which is a day of setup for a picture the RFCs state in one sentence. The other content is process, and a transcript cannot show a process.
RFC 2865, section 5.2. Free. Read the description of how the user password attribute is hidden and answer one question: does the mechanism protect any other attribute in the packet? That is the whole of the figure above, from the source.
RFC 8907. Read the introduction and answer the matching question: what portion of the packet does it obfuscate? The two answers next to each other are the distinction the exam wants.
NIST SP 800-63B. Read what it says about password expiry. It is short and it contradicts a policy your organisation probably still has, which makes it worth reading before the next time somebody defends that policy in a meeting.
Then ask for a list. Whoever administers accounts where you work can produce a list of accounts that have not logged in for ninety days. It takes them a minute and it is the most interesting document in the building.
What trips people up
1. Treating a refused action as a failed login
Authentication succeeded. Authorisation refused. Those are different failures with different fixes, and a log that records the second as the first sends somebody hunting a compromise that did not happen.
2. Counting two things you know as two factors
A password and a security question are the same category. Multifactor means evidence from different categories, and anyone who phished one has usually phished the other.
3. Assuming RADIUS protects the session
It conceals the password attribute and nothing else. On the wire, the username and the rest of the exchange are readable, which is why it is the wrong choice for administrative access to devices.
4. Calling SAML a login protocol
It federates identity so one organisation’s users are accepted by another’s application. It is not doing the same job as RADIUS or LDAP, and the exam’s list invites the confusion.
5. Granting access to people instead of roles
It works until somebody changes jobs, and then the old access stays because nobody remembers it was granted. Roles make the question what can this person do answerable.
6. Relying on geofencing as a control
It is a useful signal and it is defeated by anybody who cares. Use it to raise suspicion, not to make a decision.
Work it through
The contractor’s account, and what to do in what order.
Start by establishing what it is rather than who it belongs to. Is it an interactive account somebody logs into, a service account something else uses, or a shared account with the credentials in a document. The three need different handling and the third is the one that becomes an argument.
Then find out what it can reach, which is a harder question than it should be if access was granted per person. That difficulty is itself the finding, and it is the argument for roles that the section above makes.
Then check whether it has been used since March. If it has not, disable it and move on. If it has, that is an incident rather than a housekeeping task, and the next question is from where and to do what, which is the accounting half of AAA earning its place.
Then fix the class rather than the instance, because there will be others. Ask how the account was created, and whether the source it came from is one the leavers process reads. For contractors the answer is usually no, and that gap is the actual defect.
And put an expiry on it if it has to stay. An account that closes itself unless somebody deliberately renews it converts this from a thing you have to remember into a thing that happens by default, which is the only version that survives a busy year.
Try it
Ask for the stale account list. Ninety days without a login. Every organisation can produce it and almost none look at it.
Check whether your own second factor is a second category. If both things are things you know, it is one factor wearing two hats.
Read section 5.2 of RFC 2865. Two minutes, and it settles the RADIUS question permanently.
Check yourself
Somebody logs in successfully and is refused when they try to do something. Which control refused them, and is it a security incident?
Authorisation refused, and no.
Authentication answered who are you and got a good answer: real account, correct credential. Authorisation answered what may you do and said no, which is the correct outcome for somebody legitimate who should not have that access.
It only becomes interesting if the person should have had it, which is a provisioning problem, or if they are attempting things repeatedly, which is worth looking at. A log that records this as a failed login sends somebody hunting a compromised credential that does not exist.
Is a password plus a security question multifactor?
No. Both are things you know, so it is one category twice.
The word factor refers to the category: something you know, something you have, something you are. The value of a second factor comes from it failing differently from the first, and two things you know fail the same way. Somebody who phished a password has usually phished the answer to the question on the same page.
Why is TACACS+ the better choice for administrative access to network devices?
Because of what each protocol conceals.
RADIUS hides the user password attribute and leaves the rest of the packet readable, so an observer on the wire learns the username and the content of the exchange. TACACS+ encrypts the whole body, so an observer learns that a login happened and between which addresses.
For network access, where the readable content is mostly a username, that matters little. For somebody administering a device, the readable content is the commands they ran, which is a considerable difference. TACACS+ also separates authentication from authorisation properly, so it can decide per command.
How does an account for somebody who left in March survive a leavers process that was followed correctly?
Because the person was not in the system the process reads.
A leavers process usually starts from employment records, and contractors frequently are not in them. They exist in a purchase order or an email thread, so they never appear on the list and the process runs correctly over a population that does not include them.
The cheap fix is an expiry date on the account, so it closes unless somebody renews it deliberately. The real fix is creating accounts only from a source of record that includes contractors.
Single sign-on makes the leavers problem better. What does it make worse?
The value of one stolen credential.
Forty separate systems is forty leavers problems, and single sign-on collapses that to one, which is a genuine improvement in exactly this failure. It collapses the blast radius identically: one credential now opens forty systems.
Which is why multifactor stops being optional alongside it. It also leaves at least one account outside the mechanism, because somebody has to be able to fix the identity provider when it is unreachable, and that account needs its own protection.
References
- RFC 2865 - IETF, RADIUS, whose section 5.2 describes hiding the user password attribute and no other. Free. Accessed 2026-08-11.
- RFC 8907 - IETF, TACACS+, which obfuscates the whole body. Free. Accessed 2026-08-11.
- IEEE 802.1X - IEEE Standards Association, the port-based access control these servers sit behind. Scope readable without purchase. Accessed 2026-08-11.
- NIST SP 800-63B - NIST, digital identity guidelines, including what it says about password expiry. Free. Accessed 2026-08-11.
Where the numbers came from. Nothing on this page is captured. The RADIUS and TACACS+ difference is stated by RFC 2865 and RFC 8907 respectively, and demonstrating it properly would need a working server of each, which is a day of setup for a picture the documents give in a sentence. The ninety day figure in the stale account exercise is a common review interval rather than a standard. The thirty second interval for time-based codes is the usual configuration and not a requirement.
If you also work on Linux. Central identity covers joining a machine to a directory, and authentication and PAM covers the stack that decides whether a login succeeds. Both are the implementation underneath this page’s vocabulary.