Maintenance
Part of Account administration decisions that are cheap now and costly later
How to test account administration software with a joiner-leaver drill
No ranking of account administration software for 2027. Run a joiner, mover and leaver drill instead, then count the systems that will never connect.
This page will not rank identity and administration products because the decision is almost entirely determined by things outside the product. There is no best of 2027 list here, and that is deliberate. The 2027 account administration category overview covers the category and how the products differ. This page covers the drill you run on your own estate.
They include how many systems you run, how people join and leave, and what you must prove to someone else.
What can be written down is a drill. Run the same joiner, mover, and leaver sequence through every candidate and time it. The differences that matter turn up in the first hour.
What to take away
- Evaluate on the lifecycle, not the login. Signing in is the easy part and every product does it.
- Time the leaver case specifically. It is the one that carries real risk and the one demonstrations skip.
- Recovery is the design problem hiding behind authentication. Ask how a locked out person gets back in before you ask anything else.
Why a ranking would mislead
Three variables decide this and none of them is visible to a reviewer.
How many separate systems hold accounts, and how many connect to anything?
The shape of your workforce matters: an organization with contractors joining monthly faces a different problem than one with ten permanent staff.
What you must be able to demonstrate: an obligation to show who had access to what on a given date changes requirements more than any feature.
An ordering that ignores those three has answered them for you, silently, with somebody else's values.
The drill
Set a timer and do the same thing in each candidate. Use a real role, not a test account called test.
Joiner-leaver drill steps
- Create new person with real access
- Time it, then time manual parts
- Move to new team, remove old access
- Suspend and check active sessions
- Reinstate and see what returns
- Remove entirely, trace files and groups
- List who had access three months ago
The timings below are typical for a mid-sized estate with a handful of connected systems. Yours will move with the number of systems you run.
- Joiner, create. Add the new starter with the access their role needs. Typical time: 10 to 15 minutes once a role template exists, longer the first time.
- Joiner, verify. Sign in as the new user to every system the role touches. Note each system that needed a manual step. Typical time: 30 to 45 minutes, most of it waiting on provisioning.
- Mover, remove. Move the same person to a new team and check that the old access is gone rather than layered over. Typical time: 15 minutes, plus one sync interval for the product.
- Leaver, disable. Disable the account and time how long the last connected system keeps accepting the credentials. This step is a measurement, so write the number down and do not accept a written claim.
- Leaver, revoke. End active sessions and tokens. Confirm the person cannot return from a device they still hold. Typical time: 10 minutes where the product supports it at all.
- Leaver, verify. Check from the systems side, not the console, that access has ended. Typical time: 20 minutes across a small estate, longer where you must check by hand.
- Leaver, reconstruct. Ask for the access the person held on a date before they left, delivered as a file an auditor would accept. Typical time: 10 minutes where the product keeps history. Some products cannot answer this at all.
Authentication questions worth asking out loud
Multi factor authentication is universal now, which means the interesting questions are about the edges rather than about whether it exists.
Which methods are supported? Can administrators require a stronger one than everyone else? What happens if someone loses the device holding their factor? How long does recovery take?
Can a factor be enrolled from an unmanaged device, and should it be? Is there a break glass account, where is it kept, and who knows?
The published digital identity guidelines are the reference text for how authenticators should behave across their whole life, including binding and recovery. The document is NIST Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management. Reading the recovery sections before a purchase is a good use of an afternoon.
For practical rollout, the advice on multi factor authentication for corporate services is shorter and covers the arguments you will have with colleagues. The publisher is the UK National Cyber Security Centre.
Count the systems that will not connect
Every product in this category is sold on the picture where all your applications sit behind one sign in. Your estate will not look like that.
Connectable vs unconnectable systems
Standard protocol
- Reason
- Supported
- Account count
- Count here
- Risk level
- Lower
- Benefit of directory
- Full control
Cannot connect
- Reason
- Old, costly, wrong tier
- Account count
- Count here
- Risk level
- Often highest
- Benefit of directory
- Administration only
Make two lists. Systems that can be connected using a standard protocol, and systems that cannot, whether because they are old, because the connector costs more, or because the supplier only supports it on a tier you are not buying. Then count how many accounts sit in the second list.
If most of your risk lives in the second list, a directory product will improve your administration without much improving your exposure, and you should know that before you buy rather than after. It is still worth doing. It is just a different benefit from the one on the brochure.
What to test that nobody demonstrates
- Bulk changes. Move thirty people between groups and see whether the interface can do it without a spreadsheet import and a prayer.
- Delegation. Can a team lead approve access for their own team without becoming an administrator of everything?
- The report. Produce evidence of who has what, as a file, without a support case.
- The bad day. Simulate the identity product itself being unavailable and find out what still works and what does not.
The fourth is uncomfortable and worth an hour. Putting every system behind one sign in concentrates a failure as well as a control, and the answer to what happens then should be a plan rather than a shrug.
What the decision usually comes down to
For most organizations, it is one of two things. Whether the directory already included in a suite you pay for covers enough of the estate, which is often the honest answer.
Whether your support arrangement can run the recovery path at 3 p.m. on a Friday.
The category overview covers what these products differ on structurally, and the cost model covers the tier boundaries where the useful controls tend to sit. The first is the 2027 account administration category overview. The second is the account administration cost model.
Where to read next
If the estate is small enough that a full directory is not obviously worth it, separation of roles in a small mail estate shows the minimum honest arrangement.
If mail is the system carrying the most sensitive access, mail security notes cover the specific attack this category is bought to prevent. Whatever you choose, the administration questions in the storage estate end up answered here rather than there.
Common questions
Is the directory built into our office suite good enough?
Very often, and it should be the first candidate rather than the fallback. Check it against the drill above, particularly steps three and seven. If it passes, the money is better spent elsewhere.
How long should an evaluation take?
The drill takes a morning per product. The part that takes longer is the inventory of systems, which is genuinely useful whether or not you buy anything and which most organizations have never done.
Should we require the strongest authentication for everyone?
Start with administrators and anyone who can approve a payment or change a bank detail, then widen. Requiring the strongest method organization wide on day one produces a support queue that undermines the whole program, and the exceptions granted under pressure become permanent.
What happens if the identity provider itself has an outage?
Ask the question during evaluation and write the answer down. You want to know which systems fail closed, which fail open, and whether there is a documented path back in that does not depend on the product being available. A supplier who has never been asked this is telling you something.
