NHI Programme Roadmap: Discovery to Governance

Most non-human identity programmes stall after the first inventory, because nobody has set out what comes next, in what order, and how to know a stage is finished. Service accounts, API keys, OAuth grants, certificates, workload identities and AI agents outnumber people in most estates, and the work to govern them spans cloud, platform, application and security teams. This roadmap breaks an NHI programme into six stages with entry conditions, deliverables, exit criteria and the dependencies between them, from mandate and discovery to continuous governance. It is for security leaders, identity architects and programme managers building or rescuing an NHI programme. It complements the NHI Governance Maturity Model, which tells you where you are; this page tells you the order in which to move. Durations given are illustrative planning ranges, not benchmarks: set your own from your estate's size and team capacity.

Key takeaways

Sequence by dependency, not by tool. Ownership depends on inventory, rotation depends on ownership, and automated lifecycle depends on both. Buying a platform does not let you skip a stage.
Contain while you discover. Leaked secrets and privileged orphans found in the first weeks should be fixed immediately, not held for the formal remediation stage.
Every stage needs an exit test. "Inventory complete" means a measured coverage figure per source, not a finished spreadsheet.
Modernise authentication before polishing rotation. Moving workloads to federation and short-lived credentials removes whole classes of secret, which is cheaper than rotating them forever.
Governance is a loop, not a stage. The last stage is continuous: discovery, attestation, right-sizing and detection run on a schedule and feed back into earlier stages.

What the roadmap covers and how it fits

An NHI programme has to address the risks the OWASP Non-Human Identities Top 10 (2025) lists: improper offboarding (NHI1), secret leakage (NHI2), vulnerable third-party NHIs (NHI3), insecure authentication (NHI4), overprivileged NHIs (NHI5), insecure cloud deployment configurations (NHI6), long-lived secrets (NHI7), environment isolation (NHI8), NHI reuse (NHI9) and human use of NHIs (NHI10). No single stage fixes all ten; the roadmap orders the work so each stage makes the next one possible.

Stage	Goal	Illustrative duration	Maturity level reached	OWASP risks addressed first
0. Mandate and scope	Sponsor, scope, team and success measures agreed	2 to 6 weeks	Prerequisite	None directly
1. Discovery and baseline	Know what exists, where, and what it can do	1 to 3 months	Level 2 Developing	NHI2 (leaks found), NHI1 (orphans found)
2. Ownership and policy	Every in-scope NHI has an owner, purpose and standard	2 to 4 months	Level 3 Defined	NHI1, NHI10
3. Risk reduction	Fix the highest-risk findings: privilege, stale, exposed	3 to 6 months, overlapping	Level 3 Defined	NHI5, NHI8, NHI9, NHI3
4. Modernise credentials	Federation and short-lived credentials by default	6 to 12 months	Level 4 Managed	NHI4, NHI6, NHI7
5. Continuous governance	Automated lifecycle, attestation and detection	Ongoing	Level 4 to 5	All, as a loop

Stage 0: Mandate and scope

Sponsor and decision rights: name an executive sponsor and decide who can require application teams to change credentials. Without that authority, Stage 3 fails. NIST CSF 2.0 GV.RR-02 (roles, responsibilities and authorities established and enforced) is the outcome to aim for.
Scope by type and platform: list the NHI types in scope (service accounts, API keys and tokens, OAuth apps and grants, certificates and keys, cloud roles and workload identities, CI/CD credentials, AI agents) and the platforms to cover first. Start with the platforms that hold your most sensitive data.
Baseline maturity: score each dimension of the NHI Governance Maturity Model so progress can be measured later.
Team: identity engineering, cloud platform, application security and the security operations centre each own part of the work; agree a single programme lead.
Exit criteria: signed charter, scope list, maturity baseline, and three to five programme metrics with owners.

Stage 1: Discovery and baseline

Discovery joins several sources: identity providers and directories, cloud IAM, SaaS admin consoles and OAuth grants, secrets managers, code and CI/CD scanning, certificate stores and agent platforms. Each source tells you something different, so reconcile them into one record per identity. See NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments and NHI Inventory Reconciliation.

Minimum record: identifier, platform, type, credential type and age, last used, permissions summary, creator, and any owner hint (tags, naming, repository). The Machine Identity Naming and Tagging Standard Template gives a starting schema.
Contain as you go: secrets found in public repositories, privileged identities with no owner and no use, and credentials belonging to departed staff are fixed in days, not queued. Use the Leaked Credential Response Playbook.
Measure coverage: for each in-scope platform, record whether it is connected and how complete the data is. NIST SP 800-53 CM-8 (system component inventory) and IA-4 (identifier management) are the controls this stage evidences.
Exit criteria: every in-scope platform connected or explicitly deferred; counts by type and platform; a ranked list of critical findings with actions underway.

Stage 2: Ownership and policy

Assign owners: every NHI gets a named human owner and a documented purpose. Use creator, repository and cost-centre data to propose owners, then confirm. See the NHI Ownership Guide.
Write the policy and standards: how NHIs are requested, named, authenticated, stored, rotated, reviewed and retired. The NHI Policy Template is a starting point. Make prohibited patterns explicit: shared credentials across environments (NHI8), reuse across applications (NHI9), and people signing in as service accounts (NHI10).
Link to HR and change processes: OWASP's NHI1 guidance is to review the NHIs associated with departing employees, decommission or transfer them, rotate any credentials the person could access, and automate those steps by integrating HR systems with IAM tools.
Run the first attestation: owners confirm each NHI is still needed and correctly privileged. See the NHI Ownership Attestation Campaigns Guide.
Exit criteria: owner coverage above your agreed threshold for in-scope NHIs (start with privileged NHIs); approved policy; first attestation complete with unclaimed NHIs disabled or scheduled for removal.

Stage 3: Risk reduction

With owners in place, fix the riskiest identities first. Rank by privilege, data reach, exposure (internet-facing, third-party held) and credential type. See the NHI Risk Scoring Guide.

Remove what is unused: disable, wait, then delete dormant NHIs. See NHI Dormancy Detection and the NHI Offboarding and Decommissioning Guide. Verify "unused" with logs, not assumption.
Right-size privilege: replace administrator and wildcard permissions with policies built from observed use (NIST SP 800-53 AC-6).
Separate environments and applications: split credentials shared between test and production, or between applications, so one compromise does not cross boundaries.
Review third-party NHIs: OAuth apps, integration users and vendor-held keys get an owner on your side, minimal scopes and an expiry.
Vault what remains: secrets that cannot yet be removed move to a secrets manager with rotation. See the Secrets Management Guide.
Exit criteria: no privileged NHI without an owner; critical and high findings closed or risk-accepted by the owner; secrets in code trending to zero.

Stage 4: Modernise credentials

Federate workloads: CI/CD pipelines, Kubernetes workloads and cross-cloud calls move from stored keys to workload identity federation, which issues short-lived credentials on demand. See the Workload Identity Federation Guide and the step-by-step pages for GitHub Actions to AWS and GitLab CI to Azure.
Retire weak authentication: password-only service sign-ins and legacy protocols go first; platforms are forcing the issue, as with Snowflake's deprecation of single-factor password sign-ins. See How to find Snowflake service users without key-pair auth.
Shorten lifetimes: OWASP's NHI7 guidance is to automate rotation, use short-lived credentials, require re-authentication for sensitive actions and apply least privilege. Set maximum lifetimes in policy for anything that must remain static.
Govern AI agents as NHIs: agents get their own identities, scoped and time-limited credentials, and owners, rather than borrowing a person's tokens.
Exit criteria: agreed share of workloads on federated or short-lived credentials (set per platform), no new long-lived keys without an approved exception, and exceptions with expiry dates.

Stage 5: Continuous governance

Lifecycle automation: NHIs are created through a request or infrastructure-as-code path that records owner and purpose, and retired with the workload (NIST SP 800-53 AC-2(1) automated account management and AC-2(3) disable accounts).
Recurring attestation and right-sizing: owners re-confirm need and privilege on a schedule set by risk; unclaimed NHIs are disabled automatically.
Detection: NHI activity is logged and baselined, with alerts for use from new networks, human use of service accounts and privilege changes. See the Detection Engineering for Non-Human Identities Guide.
Evidence: the programme produces audit-ready evidence on demand. See Audit Readiness for AI Agents and NHIs.
Review and improve: re-score maturity yearly and feed gaps back into the earlier stages (CSF 2.0 GV.OV-03 and ID.IM-01).

Who does what across the stages

Team	Main responsibilities	Stages where it leads
Programme lead (identity or security)	Charter, scope, metrics, policy ownership, escalation of blocked remediation	0, 2, 5
Identity engineering	Discovery connectors, reconciliation, attestation workflows, lifecycle automation	1, 2, 5
Cloud and platform engineering	Cloud IAM clean-up, workload identity federation, CI/CD credential changes	3, 4
Application and product teams	Act as NHI owners: confirm purpose, accept fixes, change application credentials	2, 3, 4
Security operations	Leak response, NHI detections, revocation drills	1 (containment), 5
Risk, audit and procurement	Exception approvals, evidence, third-party NHI terms in contracts	2, 3, 5

Name these roles in the Stage 0 charter. A common cause of stalls is a stage whose lead team was never agreed, often application teams in Stage 3 or platform teams in Stage 4.

Decision guidance: adapting the roadmap

Situation	Adjustment	Trade-off
Small organisation, one cloud, few SaaS apps	Combine Stages 0 to 2 into one effort using native cloud and IdP reports; skip a dedicated platform at first	Manual inventory must be re-run; plan automation once counts grow
Large enterprise, many business units	Run Stages 1 to 3 per business unit or platform in waves, with central policy and metrics	Slower overall, but each wave finishes properly
Recent NHI-related incident	Front-load Stage 3 containment for the affected platforms, then return to Stage 1 for the rest	Discovery elsewhere waits; document the gap
Regulatory or audit deadline	Prioritise ownership, policy and evidence (Stages 2 and 5 evidence) for in-scope systems	Risk reduction may lag the paperwork; track it openly
Heavy CI/CD and cloud-native estate	Pull Stage 4 federation forward for pipelines; it removes most CI secrets quickly	Requires platform team capacity early

Build or buy: native tools (cloud IAM reports, IdP and SaaS admin logs, secret scanners) are enough for Stages 1 and 2 in smaller estates. A dedicated NHI platform earns its cost when you have many platforms to reconcile, need continuous discovery, or need owner workflows at scale. Decide at the end of Stage 1, when you know the counts.

Measuring progress

Metric	What it shows	Stage it tracks
Platforms connected to inventory, as a share of in-scope platforms	Discovery coverage	1
NHIs with a confirmed owner, overall and for privileged NHIs	Accountability	2
Privileged NHIs unused for 90 days	Standing risk from stale access	3
Long-lived secrets in use, and secrets found in code per month	Secret exposure	3 and 4
Workloads on federated or short-lived credentials	Modernisation	4
Median time to revoke a leaked credential	Response capability	All
Attestation completion rate and unclaimed NHIs disabled	Continuous governance	5

Report trends, not one-off counts, and set targets per platform once Stage 1 gives you real numbers.

Framework mapping

Framework	References	Where in the roadmap
NIST CSF 2.0	GV.RR-02, GV.PO-01; ID.AM-02; PR.AA-01, PR.AA-05; DE.CM-03; GV.OV-03, ID.IM-01	Mandate and policy; inventory; credentials and least privilege; monitoring; review
NIST SP 800-53 Rev. 5	CM-8, IA-4, IA-5, IA-9, AC-2, AC-2(1), AC-2(3), AC-6, AU-6	Inventory, identifiers, authenticators, service identification, account lifecycle, least privilege, log review
CIS Controls v8.1	Control 5 Account Management; Control 6 Access Control Management	Stages 1 to 3 and 5
OWASP NHI Top 10 2025	NHI1 to NHI10	See the stage table above

Common failure patterns

Inventory as the finish line: a one-off spreadsheet goes stale within weeks. Discovery must become a scheduled job before Stage 2 ends.
Assuming "unused" without evidence: NHIs believed idle are skipped during rotation or clean-up and later abused.
Owners in name only: owners assigned by algorithm but never confirmed do not respond to attestation; the programme then cannot disable anything.
Rotating instead of removing: years of rotation work spent on keys that federation would eliminate.
Personal storage of service credentials: service account passwords saved in browsers and personal profiles leave the programme's control entirely.
Forgetting non-production: test tenants and legacy apps fall outside scope but still hold real permissions.

Lessons from incidents

Unrotated because "unused": in the Cloudflare Thanksgiving breach, a Moveworks service token, Smartsheet and Bitbucket service accounts and an AWS credential exposed in the Okta breach were not rotated because they were mistakenly believed to be unused. A Stage 1 baseline with last-used data would have shown otherwise.
Service credentials in a personal profile: in the Okta support system breach, credentials for a support service account were saved in an employee's personal Google profile on a work laptop, and the attacker reached files for 134 customers. Stage 2 policy (no human use of NHIs, approved storage only) addresses this.
Password-only service access at scale: the Snowflake breach used infostealer-harvested passwords against accounts without MFA or network allow lists, and about 165 organisations were notified. Stage 4 modernisation removes the password path.
Forgotten test assets: in the Microsoft Midnight Blizzard breach, a legacy test tenant account without MFA and a legacy test OAuth app with elevated access led to the full_access_as_app role on Exchange Online. Scope in Stage 0 must include non-production.

Practitioner checklist

Secure a sponsor with authority to require credential changes, and write the programme charter.
Define scope by NHI type and platform, including non-production and AI agents.
Score the maturity baseline and pick three to five metrics with owners.
Connect discovery sources and reconcile into one record per identity; contain critical findings immediately.
Assign and confirm owners, approve the NHI policy, and run the first attestation.
Rank NHIs by risk and remove, right-size, separate and vault in that order.
Move pipelines and workloads to federation and short-lived credentials, and set exception expiry dates.
Automate lifecycle, attestation and detection, and re-score maturity every year.

NHI Programme Roadmap: Staged milestones from discovery to continuous governance