The employee who moved departments and kept the keys

SSee · Who can actually reach what

Access builds up quietly, and the org chart does not show it.

Alex moved from Finance to Operations. HR updated the department record; the identity system did not follow. The map drawn here shows what is actually granted, not what the org chart implies, and it still contains a finance approval role and a finance data group attached to Alex.

Beside Alex sit two accounts that are not people: an admin account whose owner has left and that has not signed in for months, and a service account that was given broad data access during a project and never narrowed.

• Leftover finance access — Alex's account still carries a payments-approval role and a finance data group, although Alex no longer works in Finance.
• Dormant privileged account — An admin account with no active owner still holds its permissions and has no second factor registered.
• Service account with wide reach — It can read a sensitive data store that its actual job does not require.
• No lifecycle trigger — Nothing connects a change in HR records to a change in access.

AAssess · Why it matters

Each leftover permission is a path someone can use: by mistake, by misuse, or after a stolen password.

Excess privilege turns small events into large ones. A phished password on an ordinary account is an inconvenience. The same password on an account that can approve payments or read sensitive records is an incident. Auditors ask the same question in a calmer voice: can you show who has access, and that someone with authority agreed to it?

Removing access promptly and granting only what a job needs are core access-control practices. NIST SP 800-53 covers them under account management (AC-2) and least privilege (AC-6). They also limit blast radius: when ransomware or an intruder lands on one account, that account's permissions decide how far it can spread.

• Excessive permissions — Alex can still approve payments and read finance records. That is a separation-of-duties problem even if Alex never misuses it.
• Dormant privileged account — Unused, unowned and privileged is the profile where misuse goes unnoticed longest.
• Weak authentication — That admin account has no MFA registered, so a password alone is enough to use it.
• No lifecycle process — Removal depends on someone remembering. An audit finds it later, and fixing it then costs more.

0 of 3Privileged identities reviewed — synthetic scenario: the leftover role, the dormant admin, the service account

VValidate · Test the paths

A joiner-mover-leaver review tries the inappropriate path instead of trusting the policy.

Innovera's review takes each mover, dormant and service identity and attempts the access that should no longer exist: approve a payment, open the data store, sign in with the dormant admin. It records whether the attempt was blocked, and by which control.

The result is often uncomfortable. A control that looks complete on paper, such as MFA, blocks nothing that matters when a genuine user holds the wrong entitlement. The test shows which control closes which path, and which paths stay open. In a real engagement this is done with authorised, agreed tests and read-only inspection.

• MFA verifies the person, not the entitlement — Alex passes MFA legitimately. Only removing the access stops the payment path.
• Automation covers what it was told about — A move rule removed the role but not a related group. Reviews catch what rules did not anticipate.
• Service accounts need different controls — They cannot answer an MFA prompt, so narrow scope, owned credentials and monitoring carry the load.

EEvolve · The better state

Access that follows the person's job, and proof that it does.

A better design ties access to role and lifecycle. When HR records a move, the old access is removed and the new access is requested and approved. Privileged access is granted when needed and for a limited time rather than held permanently, and sign-ins to sensitive systems must satisfy conditional-access policy with stronger authentication.

Service accounts have an owner, one purpose and the smallest permission that serves it. Access reviews put the question to the people best placed to answer it. And because prevention is never perfect, response readiness, meaning knowing which accounts to disable first and who decides, sets how contained an incident stays.

• Least privilege by role — Access is defined by job, so a move changes access automatically and visibly.
• MFA and conditional access — Sensitive sign-ins and admin rights require stronger authentication and meet policy conditions.
• Reviews and privileged identity governance — Periodic recertification, plus just-in-time elevation for admin roles, shrinks standing privilege.
• Scoped service accounts and response readiness — Owned, narrow, monitored accounts, and a rehearsed plan for the day one is misused.

0 of 4Inappropriate paths still open — illustrative simulation with every control on

Outcomes shown are illustrative and not verified customer results. The demo uses a small scripted graph and four controls. Real environments have thousands of identities, nested groups, application-specific roles and hybrid directories, and a real review uses authorised, read-only inspection. Outcomes come from a model, not live tests, and this is not security advice for any specific environment.