Unmanaged users create IAM risk because they sit outside the source of truth that governs joiner, mover, and leaver processes. If they are not reconciled back to the directory, they can retain access after ownership changes, billing cleanup, or offboarding events. Exporting them is useful only if the result feeds access review and removal.
Why This Matters for Security Teams
Unmanaged users in developer tools become an IAM problem when they are created, inherited, or shared outside the identity processes that track joiners, movers, and leavers. That breaks accountability: no clear owner, no consistent review cycle, and no reliable offboarding trigger. The risk is not just stale access. It is uncontrolled privilege accumulation across SaaS consoles, SCM platforms, CI/CD systems, and admin portals.
NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both emphasise that lifecycle visibility is the difference between manageable access and silent drift. In practice, unmanaged users often persist because the tool owner assumes the directory team is responsible, while the directory team never sees the account at all. That gap creates audit blind spots and weakens the control evidence needed under the NIST Cybersecurity Framework 2.0.
In practice, many security teams discover the issue only after a billing clean-up, a role change, or an offboarding event has already left access behind rather than through intentional access review.
How It Works in Practice
The core failure is that unmanaged users sit outside the system of record. A developer tool may allow local sign-up, invite-based creation, or one-off admin assignment without reconciling the account back to the corporate directory. Once that happens, the account can outlive the employee, contractor, or service relationship that created it.
Security teams should treat these accounts as access exceptions, not harmless convenience. Current guidance suggests the following operational steps:
- Discover unmanaged users across repositories, CI/CD, cloud consoles, ticketing systems, and build tools.
- Map each account to a real owner, business purpose, and approval path.
- Reconcile accounts into the directory or identity governance workflow where possible.
- Apply recurring review, expiry, and removal for any account that cannot be centrally governed.
- Exporting is only useful if it feeds remediation, not if it becomes a static report.
NHIMG’s NHI Lifecycle Management Guide frames lifecycle control as the practical control plane for non-human and tool-based access. That aligns with the need to reduce standing access and prove that accounts are either linked to an authoritative source or removed. For control design, the reporting and monitoring expectations in the NIST Cybersecurity Framework 2.0 are relevant because unmanaged users are ultimately a visibility and governance failure, not just a provisioning issue.
These controls tend to break down in fast-moving engineering environments where self-service access, shared admin privileges, and tool-level invitations are normal because the tool can drift faster than the directory and review process.
Common Variations and Edge Cases
Tighter governance often increases operational friction, requiring organisations to balance developer speed against identity discipline. That tradeoff is real, especially when teams use ephemeral sandboxes, outsourced delivery, or platform tooling that was never designed for enterprise identity controls.
There is no universal standard for every developer tool, but current guidance suggests a few exceptions deserve close handling. Shared break-glass accounts may be necessary, yet they should be tightly controlled, separately logged, and rotated. External collaborators can be managed safely, but only if their accounts expire automatically and are reviewed like any other privileged access. Service-linked users are another edge case: if a tool insists on local identities, the account still needs ownership, purpose, and periodic recertification.
For broader NHI governance, NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful because unmanaged users frequently become an evidence problem during audit even when no incident has occurred. The key is to avoid treating export as a finish line. Export should trigger an ownership decision: reconcile, review, expire, or remove.
Where teams rely on local tool admins to self-govern access without a central review workflow, unmanaged users usually multiply faster than any quarterly recertification can correct.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Unmanaged users reflect weak identity and access governance. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers unmanaged non-human and tool identities lacking ownership. |
| NIST SP 800-63 | Supports identity proofing and lifecycle assurance for governed accounts. |
Inventory every developer-tool account, assign an owner, and remove orphaned identities.
