The Keys, the Ghosts and the Break-Glass Box: An Access Review Your UK Team Can Actually Finish
Photo: Justyn M. Freeman, US Air Force, Public domain, via Wikimedia Commons
Think about the last person who left your organisation. Did their cloud access leave with them, or is it still sitting there, quietly valid, waiting for someone to use it?
Identity is the front door to everything you run in the cloud. Yet in a lot of UK teams it is the thing nobody owns. It grew organically, a contractor here, a shared admin login there, and now nobody is entirely sure who can do what. This guide is about fixing that without needing a six-month project or a consultancy retainer.
Start with the awkward question: who has the keys?
The first job is a list, not a fix. Export every account from your main cloud tenancy, your identity provider, and your SaaS estate. Then sort them into three buckets:
- Root or global admin. The account that can do anything, including delete the lot.
- Service or workload admin. People who can change production, manage billing, or issue credentials.
- Everyone else. Read access, contributor rights, whatever sits in the middle.
In most organisations, the top bucket is far too crowded. A useful rule of thumb: a small team should be able to name every global admin from memory. If they cannot, you have found your first action.
Least privilege, translated
Least privilege is jargon for a simple idea. Give each person the access their actual job needs, for as long as they need it, and no more. The difficulty is that "no more" requires someone to say no, and saying no is unpopular.
A few practical versions of this that work in real UK businesses:
- Replace standing admin rights with just-in-time elevation, so a finance manager gets server access for an hour with a reason logged, not permanently.
- Split billing access away from technical access. Your finance lead does not need to be able to spin up databases to read an invoice.
- Use groups rather than individual assignments, so removals happen in one place.
- Give contractors an expiry date on day one. Not "we'll remember". An actual expiry date the system enforces.
The break-glass account deserves its own paragraph
Every tenancy needs a way in when the normal way in has broken. That is what a break-glass (or emergency access) account is for. It should be:
- Rarely used. Not your daily login with a different name.
- Locked down with phishing-resistant MFA, ideally a hardware key kept somewhere physical.
- Alerted loudly. Any sign-in should page someone, no exceptions.
- Tested on a schedule and the test written down, so you know it works before you need it at 2am on a Sunday.
- Limited to two accounts, held by two named people who are not always on the same holiday.
The failure mode here is grimly common: the break-glass account is documented in a wiki nobody reads, the password has not rotated since 2022, and the person who set it up has since moved to a competitor.
When someone hands in their notice
Offboarding is where identity hygiene quietly falls apart. Turning off the account is the easy bit. The full job looks more like this:
- Disable the account the same day, and revoke active sessions and refresh tokens, not just the password. A password reset does not always kick someone out of a live session.
- Transfer ownership. Shared mailboxes, code repositories, DNS records, cloud resources and billing contacts often live under one person's name.
- Check connected apps and personal devices that were enrolled.
- Remove them from distribution lists that carry sensitive attachments.
- Record who did it and when, in a ticket.
Movers are the sneaky version of this. Someone changes team internally and keeps every permission from their old role. Six months later they can still read the customer database. Treat a move as a leave plus a join, and you close that gap.
MFA: which flavours actually count
Multi-factor authentication is not a binary. SMS codes help, but they are the weakest option and increasingly phishable. Authenticator apps with number matching are better. Hardware security keys are better still, particularly for admins and finance staff.
Worth checking in your next review:
- Are admins required to use phishing-resistant MFA?
- Can users register a new device without any approval step?
- Are legacy protocols and old-style mail authentication still enabled because something ancient depends on them?
- Do you have conditional rules that block sign-ins from unexpected countries, or at least alert on them?
What auditors and insurers will actually ask for
When a cyber insurance questionnaire or an ISO 27001 audit lands on your desk, nobody wants a screenshot of a spreadsheet with names crossed out in biro. They want evidence of a process. In practice that means:
- The date of your last access review and how often you run them.
- Who reviewed which system, and what was removed as a result.
- Ticket references for joiners, movers and leavers.
- A documented break-glass procedure with a test record.
- MFA coverage figures across admin and standard accounts.
If your insurer asks "how quickly are leavers' accounts disabled" and the honest answer is "when someone remembers", that is a premium conversation you would rather not have. Same story if you are chasing Cyber Essentials or working towards ISO 27001.
A checklist to run before the next security review
- Export all accounts and mark the global admins.
- Confirm every global admin is still employed and still needs it.
- Check for dormant accounts: no sign-in for 90 days is a reasonable flag.
- Confirm leavers from the last 12 months are disabled and their sessions revoked.
- Verify break-glass accounts exist, are documented, and were tested in the last quarter.
- Confirm MFA is enforced for all admins without exception.
- Review connected third-party apps and OAuth grants.
- Check contractors have expiry dates.
- Assign a named owner for the next review, with a date in the calendar.
- Store the output somewhere the auditor can find it in under five minutes.
None of this is glamorous. It will not make a slide deck. But access reviews are one of the few security controls where a couple of hours of unglamorous admin genuinely reduces the chance of a very bad week.
Start with the list. Then start removing things from it.