Direct answer
An orphaned account has no current accountable owner. A shadow permission is an effective permission that does not appear in the formal record. Residual access remains after the relevant task or need has ended. An ownerless authenticator is a key, token, device or similar mechanism that still works without a valid owner or sponsor.
In plain language
A user account left active for a former employee may be orphaned. A hidden permission inherited through a group is a shadow permission. Folder access that remains after a project ends is residual access. A working API key that nobody can account for is an ownerless authenticator.
Why this matters
These four conditions may be absent from ordinary lists. They create opportunities for attack, mistaken action and uncertainty about who is accountable.
Do not confuse
- An account, a permission, an access path and an authenticator are separate objects.
- An account may have an owner and still carry a shadow permission.
- A person may remain employed while retaining access that is no longer needed for the current role.
What should you do?
- Inventory every human, service, application and agent identity.
- Assign an owner, sponsor, purpose and review date to each identity.
- Calculate effective authority from both direct permissions and group membership.
- Review long-unused tokens, keys and accounts.
- Reconcile HR, official-register and system records.
- Before disabling an item, identify dependencies and prepare a controlled recovery plan.
How do you audit it?
- Is there an account without an owner or sponsor?
- Does authority arise through a path that is absent from the formal role record?
- Does access continue after the task or contract has ended?
- Is there a shared authenticator or one whose controller is unknown?
- Are last use, purpose and review date recorded?
Limit
Not every unused account is malicious. If its owner, purpose and continuing need cannot be proved, however, it should be treated as a risk.
Remember in one sentence
Do not leave access open when its owner, purpose and current need cannot be proved.
Sources for this record
- S24NIST SP 800-63-4, *Digital Identity Guidelines*Standard
- S25NIST SP 800-63B-4, *Authentication and Authenticator Management*Standard
- S26NIST SP 800-53 Rev. 5, *Security and Privacy Controls*Standard
- S27IETF, RFC 7644, *System for Cross-domain Identity Management: Protocol*Standard
- S28IETF, RFC 9967, *SCIM Roles and Entitlements Extension*Standard
- S29Microsoft Learn, *Application and Service Principal Objects in Microsoft Entra ID*Provider documentation
- S30Microsoft Learn, *Managed Identities for Azure Resources*Provider documentation