A dormant account is a door left unlocked in a building everyone assumes is secure. It doesn't announce itself. It doesn't cause an incident on Tuesday. It simply sits there — a valid login, with real access to real transactions — until the day someone uses it, or an auditor asks why it exists.
The reason inactive accounts are the number-one recurring finding isn't that teams are careless. It's that offboarding and access-review run on completely different clocks. People leave continuously. Access gets reviewed periodically. In the months between those two events, the risk just accumulates.
Why they persist across every system
The account you deactivated in the HR system is not the account that matters. What matters is whether the corresponding SAP user is still live — across every client, in every system in the landscape. And that's where the gaps hide:
- A user is locked in the production system but still active in a secondary one.
- An employee changes roles internally, so nobody triggers an offboarding at all.
- A service or technical account has no human owner, so no process ever flags it.
- The termination happened in the directory, but the SAP side was never reconciled.
None of these are exotic. They're the ordinary friction of running a large landscape — and they're exactly why "we deactivate leavers" and "we have no dormant accounts" are two very different statements.
A terminated employee's account isn't dangerous because they'll come back and use it. It's dangerous because it's an unmonitored, fully-authorized credential that anyone who obtains it can use — with a legitimate name attached, drawing no attention.
Annual review versus continuous watch
The traditional control for this is the User Access Review — a periodic, often annual, exercise where someone exports the user list and works through it. It's necessary, and it's also structurally too slow. Here's the contrast:
| Periodic access review | Continuous detection | |
|---|---|---|
| Cadence | Once or twice a year | On a schedule you set, every run |
| Exposure window | Up to a full year months | Down to your review interval days |
| Effort | A project, every time | A background report |
| Coverage | Whatever got exported | Every system, every run |
| Freshness at audit | As old as the last review | As recent as the last run |
The goal isn't to replace the formal review — auditors still want it, and it still has value. The goal is to make sure the review never surfaces anything, because the dormant accounts were already flagged and cleared weeks earlier.
Detect-only, on purpose
There's an obvious temptation here: if the agent can find a dormant account, why not let it lock the account automatically? Because the cost of a wrong automatic lock is real. Lock the wrong service account and you can break an interface, a batch job, a downstream system — at 2 a.m., with no human in the loop.
The Inactive User Agent flags dormant dialog users beyond your chosen threshold and reports them. It does not lock, delete, or change anything in SAP. A person decides what happens to each account — because "this looks unused" and "this is safe to disable" are not the same judgment.
That restraint is the feature. An agent that surfaces the right accounts and then stops is something a security team can run with confidence. An agent that starts disabling things on its own is something they'll switch off after the first bad morning.
You don't have a dormant-account problem because you're careless. You have one because people leave every week and access gets reviewed every year. Close that gap and the finding disappears.
The bottom line
Dormant accounts are the most fixable finding in SAP security — the mechanism is simple, the risk is well understood, and the remediation is routine. What's missing is timing. Move the detection from once-a-year to always-on, keep a human in charge of what actually gets disabled, and the single most common audit finding stops being a finding at all.
Find the accounts that outlived their owners
See the Inactive User Agent surface dormant and terminated-user accounts across your landscape — report-only, on your infrastructure, with your team deciding what happens next.
Frequently asked questions
What is a dormant SAP account?
A valid SAP login with real access to real transactions that nobody is actively using — the contractor who left, the service account nobody owns, the manager who changed teams but kept the access. It causes no incident until someone uses it or an auditor asks why it exists.
Why are inactive accounts the number-one recurring SAP audit finding?
Because offboarding and access review run on different clocks. People leave continuously; access is reviewed periodically. In the months between those events, dormant-account risk simply accumulates — and gets discovered a year too late.
Why do dormant accounts persist across every SAP system?
Because deactivating a user in HR or Active Directory doesn't deactivate the corresponding SAP user — and that user can be live across multiple clients and systems in the landscape. The gaps hide in the systems where the lock never propagated.
Does the inactive-user agent delete accounts automatically?
No. It's detect-only: it surfaces dormant and orphaned accounts continuously and assembles the evidence, but locking or removing an account is a human decision applied by your SAP team.