A 2026 study by Orchid Security, an identity-security firm, analyzed access across organizations in multiple industries and landed on a number that's hard to explain away: 40% of the accounts found belonged to people who no longer work there. In some environments, that share topped 60%.
The cause isn't a missing tool. It's that the list of who can access what is, in most companies, an exercise that happens once a year, done by hand, and is already stale the next day. A role changes, a project ends, a vendor leaves — and the access stays.
For whoever owns security and compliance, the number that matters isn't "there are leftover accounts." It's that nobody knows, at the moment they ask, how many of those accounts can still do something.
The size of the problem, in numbers
The same Orchid Security study found something worse than simple leftover accounts: 22% of orphaned accounts still held elevated privileges — meaning people who already left kept administrator-level power in some system. And a meaningful share of machine and integration accounts — the kind one system uses to talk to another — never passed through the company's central identity control, according to the same report.
That kind of account is the most common blind spot. An application account gets created for a project, a one-off integration, a test. The project ends, the person who created the account changes teams or leaves, and the credential stays behind — usually set to never expire, because expiring it "might break something" nobody is quite sure about.
The risk of a valid credential isn't hypothetical. According to Verizon's 2026 Data Breach Investigations Report, as covered by Descope, credential abuse shows up in 39% of the breaches analyzed, at some point in the attack chain, and 28% of cases had credentials among the compromised data. A valid credential, on an account nobody is watching, is exactly the kind of door that attack looks for.
Why the annual review doesn't fix it
The most common answer is still the spreadsheet: once a year, someone in IT exports the user list for each system, sends it to managers to confirm by email, and waits for a reply. That process has three problems at once.
The first is staleness. Between one review and the next, people change roles, contracts end, projects wrap up — and access that made sense in January may make no sense at all by July. The second is coverage. Application, integration, and project accounts rarely show up in those spreadsheets, because they don't have an obvious human "owner" to confirm or deny.
The third problem is what compliance auditors call a missing trail. It isn't enough for the review to have happened: it has to show who reviewed it, when, and against which real system — not against a copy of a list from months ago. According to material on access auditing for the ISO 42001 standard, which governs artificial intelligence management systems, the auditor checks whether reviews happen on a consistent cadence and whether each one shows the reviewer, the date, and the decision made — a review without that trail doesn't count as evidence, even if it was actually performed.
What changes when review is continuous
ISO 27001, in its control over access rights, calls for review at defined intervals, with administrative privilege reviewed more often than standard access — common practice is quarterly for privileged access and annually for the rest. The requirement isn't new; what changes is how it's met.
When access is reviewed continuously instead of once a year, three things stop depending on a spreadsheet. The first is where access comes from: if it's tied to a person's corporate identity, leaving the company already means losing access, without waiting for the next review round. The second is granularity: reviewing "person X has access to system Y" is easier to get wrong than reviewing "person X has role Z inside system Y" — and that second question is the one a real review needs to answer.
The third is the application account. Tools created for a project, an integration, or a specific test need an owner, a deadline, and a recorded reason — otherwise they turn into exactly the kind of orphaned account the Orchid Security study found by the thousands.
What has to be in place
A well-reviewed access environment rests on concrete mechanisms, not on the goodwill of whoever remembers to tell IT.
Entry through corporate identity. Access to AI and connected tools uses the same corporate directory as the network — the same badge, so to speak. When someone leaves the company directory, access drops along with it, at the same instant, without depending on a second manual step.
Access by role, not by person. Each function inside each system is granted specifically to whoever holds that role — not a broad permission "because it was faster that way."
A deadline and an owner for temporary access. Every account created for a project, an integration, or a test has a responsible person and an expected end date, instead of staying active by default until someone notices.
An audit trail of who granted what. Every access grant, change, or removal is logged with who made the decision and when — the kind of evidence a compliance audit asks for, and a spreadsheet full of emails doesn't deliver.
This is how Skyller was designed: identity coming from the company directory, access according to each person's role, and an audit trail by default, not as an extra step at year's end.
The payoff for whoever owns compliance
For whoever prepares an audit — of information security, financial controls, or, increasingly, AI use — the practical value of continuously reviewed access shows up when answering the simplest and most feared question: "who has access to this, and why?"
Standards that govern financial controls require access review to follow the same rhythm as the quarterly report, with someone independent confirming that each access still makes sense — and with proof that whatever was flagged for removal was actually removed, not just logged in a ticket. An environment where that trail already exists by design turns audit prep from a weeks-long project into a query that takes minutes.
There's also a less-talked-about gain: the IT team's own time. Every hour spent chasing managers to confirm an access spreadsheet is an hour that isn't going toward what actually protects the company.
A checklist for the next access review
Before opening one more annual spreadsheet, it's worth bringing these questions to the conversation with security and compliance:
- How many active accounts today belong to people who no longer work at the company? If answering requires a manual sweep, the real number is probably larger than anyone imagines.
- Do application and closed-project accounts have a recorded owner and deadline? If not, they don't show up in any review — and they're exactly the ones that pile up the most.
- Does the last access review show who reviewed it, when, and against which system? A review without that trail won't hold up in an audit, even if it was done in good faith.
- Is access tied to corporate identity, or to loose per-system logins? Without that link, taking someone off the company payroll doesn't automatically shut off the access they accumulated along the way.
