The incident began with an invoice, not an alert. A former external contractor still had administrator access to a SaaS account three months after the project ended. The user was known, but nobody had seen the access in the offboarding list. The company had a password manager, a user list and an IT provider. It did not have a complete view of access ownership
What the retrospective found missing
The account used a personal email address. The application did not support central sign in. The business owner assumed IT managed users; IT did not know the service was in production. Logs were available for only 30 days. The access was technically visible but organisationally homeless
An access management overview must close precisely this gap. It does not store passwords. It records systems, owners, roles, identity sources, privileged accounts and review dates
Joiner, mover, leaver is no longer the whole model
Joining, changing role and leaving remain the core. Modern companies also have external partners, temporary project roles, service accounts, API keys and agents. Some identities do not belong to a natural person. They still need an owner, purpose, limited rights and expiry
Accounts absent from a central directory are particularly dangerous. Card expenditure, browser extensions, DNS records and password managers can reveal these systems. The overview draws on several signals, not an annual survey alone
A small, useful data structure
- system name, purpose and criticality
- business and technical owner
- identity provider or local account model
- roles and their effective permissions
- administrators and emergency accounts
- external and non human identities
- last access review and next due date
- logging scope, recovery and shutdown route
The overview must not become a secret second user directory. The identity provider or individual application remains the system of record. The overview exposes gaps, accountability and review results
Passkeys change authentication, not accountability
Current digital identity guidance explicitly includes syncable passkeys. They offer a phishing resistant route without a shared password and can simplify use. For critical systems, the appropriate assurance level, secure enrolment and account recovery remain essential
A strong login does not prevent a person having excessive rights. Authentication answers who is signing in. Authorisation determines what that identity may do. The two controls require separate review
Least privilege as a difference, not a slogan
The practical question is: which rights does a role have today, and which does it need for observed work? Remove or justify the difference. A role called “manager” means nothing without a description. An effective role map lists concrete actions such as invite users, change billing details, export or delete
Time limited rights are useful for migration and support. An approval records a start, expiry and reason. Permanent administrator rights “just in case” are not an emergency strategy. Separate, strongly protected emergency accounts serve that purpose and raise an alert when used
An access review as a real conversation
A quarterly email listing 200 names usually receives a blanket approval. Smaller, risk based packages work better. An owner sees only their systems, unusual changes and privileged roles. Every decision to retain or remove access is recorded
Unclear entries cannot be deferred forever. A missing owner triggers a defined escalation. If an identity cannot be attributed, its access is restricted through a safe procedure
Offboarding in hours rather than weeks
Departure centrally disables connected accounts. Local systems create tasks with a deadline and confirmation. Active sessions, API keys, personal forwarding and shared resources receive separate treatment. Data ownership moves to a named person before deletion
The result is not a tick marked “done” but an evidence trail: which access was disabled automatically, which was confirmed manually and which exception remains open
A 30 day plan for a small business
- record critical systems and their owners
- review every administrator and external account
- enable central sign in and multifactor authentication where possible
- add deadlines for offboarding local accounts
- separate, protect and test emergency accounts
- complete the first risk based access review
The AI tool register extends this view to models, data flows and agentic permissions. A good access overview does not ultimately deliver a perfect spreadsheet. It gives a dependable answer to three questions: who can act, why may that person or machine act, and who notices when the permission is no longer right?
