Maintenance
Part of Account administration decisions that are cheap now and costly later
A drill to assess best account administration software 2027
Use a joiner-mover-leaver drill to assess best account administration software 2027 against your systems, access changes, recovery, and audit evidence.
This page does not rank identity and administration products. Use the drill below to assess best account administration software 2027 against your own estate; the decision depends on factors outside the product. The drill makes those factors testable on your own systems.
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 emerge when you run the same tasks. Examples to evaluate include Microsoft Entra ID, Okta, Google Workspace, JumpCloud, OneLogin, and Ping Identity; this is not a ranking, and suitability depends on your requirements.
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
Do not use generic “typical” durations as a pass-or-fail benchmark. For each candidate, start a timer at the first administrative action and record elapsed time to completion, plus any wait for provisioning or sync. Use the same role, systems, and starting conditions for each candidate.
- Joiner, create. Add the new starter with the access their role needs. Record elapsed time and whether a role template already existed.
- Joiner, verify. Sign in as the new user to every system the role touches. Note each system that needed a manual step, and record how long provisioning took to produce usable access.
- Mover, remove. Move the same person to a new team and check that the old access is gone rather than layered over. Record elapsed time and the sync interval or connector path observed.
- Leaver, disable. Disable the account and measure the time until the last connected system rejects the credentials. Record the system, elapsed time, and provisioning path, such as SCIM deprovisioning or agent-based sync. Test it rather than accepting a written claim.
- Leaver, revoke. Revoke active sessions and invalidate refresh tokens where supported. Confirm the person cannot return from a device they still hold, and record which actions worked and how long access took to end.
- Leaver, verify. Check from the systems side, not the console, that access has ended. Record the systems checked and elapsed time, including any manual checks.
- Leaver, reconstruct. Ask for historical access as a CSV file for a specified date before the person left. Record whether the export identifies the systems, roles, and access status, and how long it takes to receive a usable file. Check the evidence against your audit obligations; no file format is universally accepted by every auditor.
Authentication questions worth asking out loud
Multi-factor authentication is more useful to evaluate as a set of methods and recovery options than as a checkbox.
Which methods are supported: FIDO2/WebAuthn security keys, passkeys, TOTP codes, or push approvals? 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 separately protected break-glass account, where is its credential kept, who can retrieve it, and is its use monitored?
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. For account provisioning, check whether a system supports SCIM; for sign-in federation, check SAML 2.0 or OpenID Connect; for directory access, check LDAP. Use the standard protocol information to check what each connector actually supports. A sign-in connection does not by itself prove that account provisioning or deprovisioning works. Then list systems that cannot connect, whether because they are old, because the connector costs more, or because the supplier only supports it on a tier you are not buying. 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 a CSV export of who has what, without a support case. Check whether it shows access for a specified date and includes the details you need for review.
- The bad day. Simulate the identity product itself being unavailable and find out what still works, what does not, and how a separately protected break-glass account can be used.
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 useful controls may sit.
Where to read next
If mail is the system carrying the most sensitive access, mail security notes cover the specific attack this category is bought to prevent.
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's duration depends on the estate and how quickly each system can be checked. Inventory the systems first; that work is useful whether or not you buy anything.
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.
