NHI 30/60/90 day plan template for a new programme: Goals, owners and evidence for the first quarter

New non-human identity (NHI) programmes lose their first quarter to tool deployment and inventory debates, and reach day 90 with a long list of findings but nothing fixed and no agreed owner for machine identities. A 30/60/90 day plan forces early decisions: who owns NHIs, which environments come first, which risks get fixed first, and what evidence proves progress. This template is for the person who has just been asked to stand up an NHI programme, whether a new NHI lead, an IAM manager or a cloud security lead, and for the sponsor who will judge the first quarter. It covers mandate, governance, the three phases with goals, tasks, owners and exit evidence, metrics and the day-90 report. Durations, counts and targets are illustrative: set your own from the baseline. For the multi-year view, see the NHI Programme Roadmap.

How to use this template

• Replace text in square brackets, such as [Organisation], [Sponsor], [NHI Lead], [Cloud Platform] and [date], with your own values.
• Keep each phase to three to five goals. A 90-day plan with twenty goals is a backlog, not a plan.
• Every task needs an owner from outside the security team where the work happens in their systems, for example the platform team for cloud roles or application owners for secrets in code.
• Exit evidence is what you will show the sponsor at the end of each phase: a report, a signed policy, a closed set of tickets. If you cannot name the evidence, the goal is not specific enough.
• Figures shown are illustrative placeholders, not benchmarks.

1. Mandate and scope

See the Non-Human Identity (NHI) Guide for definitions you can adopt.

2. Governance and roles

Record the split in a RACI. See the Security RACI Matrix Template and the NHI Ownership Guide.

3. Days 1 to 30: mandate, baseline and quick containment

Phase goal: know roughly what exists, who owns the programme and which exposures are urgent, and fix the few things that cannot wait.

Disable before you delete. For any identity you are not certain is unused, disable it, observe for [14 to 30] days and delete only when nothing breaks. This is the safe rollback path for the whole programme. See the NHI Dormancy Detection guide.

4. Days 31 to 60: ownership, policy and prevention

Phase goal: every in-scope NHI is on its way to having an owner, the rules are written, and new problems are prevented at the source.

Use the NHI Policy Template, the Machine Identity Naming and Tagging Standard Template and, for a platform decision, the NHI Security Platform Buyer's Guide.

5. Days 61 to 90: remediation, detection and reporting

Phase goal: measurable reduction in the riskiest NHIs, detection running, and a funded plan for the next two quarters.

See the Detection Engineering for Non-Human Identities Guide, the Secrets Rotation Runbook Template and the NHI Ownership Attestation Campaigns Guide.

6. Metrics

Capture each metric at day 0, 30, 60 and 90. Targets are illustrative; set them from your baseline.

For definitions that align with wider identity reporting, see the Identity Security Metrics Guide.

7. Risks and dependencies

• Access for discovery: read-only roles in each platform need approval from their owners. Request them in week one.
• Application team capacity: remediation competes with feature work. Agree with engineering leadership how many hours per team per sprint go to NHI fixes.
• Breaking production: rotation or disabling can stop services. Use the disable, observe, delete pattern and standard change windows, and keep the previous secret version available for rollback.
• Owner non-response: define the escalation path and what happens to unowned NHIs after [30] days, for example disablement after sponsor approval.
• Inventory growth: discovery usually finds more than expected. Plan for the count to rise before it falls.

8. Day-90 report outline

1. What exists: inventory by type and platform, with coverage gaps.
2. What changed: metrics at day 0 and day 90, remediated items, controls enabled.
3. What remains: top residual risks with register references.
4. Decisions needed: tooling, budget, policy exceptions, scope expansion (for example AI agents, certificates, OT).
5. Next plan: goals for days 91 to 270, aligned to the NHI Governance Maturity Model level you are targeting.

Implementation guidance

Adapting the plan

• Small organisation: one cloud, one directory and one code platform. Combine goals 2 and 3, use native credential reports and scanners, and keep the metrics table to four lines.
• Large or regulated organisation: pick one business unit or platform as the first-90-day pilot and scale the pattern in the next quarter. Bring audit in at day 30 to agree the evidence format.
• After an incident: move containment (goal 4) to week one and run the leaked secret response before inventory is complete.
• AI agents in scope: add agents and their credentials to the inventory in phase one, but defer controls until the core NHI policy exists. See the Agent Identity and Access Guide.

Detection starting points for goal 13

Begin with signals your platforms already log, so detections can go live in phase three without new tooling:

• Active Directory: Event ID 4624 with logon type 2 (interactive) or 10 (remote interactive) for accounts in your service account group or naming pattern.
• AWS: CloudTrail CreateAccessKey on privileged IAM users, and API calls from an access key out of its normal source IP range or region.
• Entra ID: audit events for credentials added to service principals or applications, especially outside change windows.
• Secrets managers: unusually high volumes of secret retrieval by one identity in a short period.
• Source control: push protection bypasses and new secret scanning alerts on repositories with production credentials.

Test each rule with a planned, approved event in a non-production environment and record the test as exit evidence.

Common failure patterns

• Tool first, mandate later: a platform is deployed before ownership is agreed, so findings have nowhere to go.
• Inventory perfectionism: the programme waits for a complete inventory before fixing anything. Fix the obvious high-risk items in phase one.
• Deleting without observing: an identity believed unused is deleted and a batch job fails at month end. Always disable first.
• Containment without revocation: a leaked key is removed from code but not revoked, so it stays valid. The Toyota T-Connect Key Exposure shows how long an exposed key can remain usable when nobody checks.
• No exit evidence: the day-90 review becomes a narrative rather than numbers, and funding for the next phase is harder to win.

Framework alignment

Standards and references

• OWASP: Non-Human Identities Top 10
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• CIS: Control 5 Account Management

Related NHI Mgmt Group resources: NHI Programme Roadmap · NHI Policy Template · Service Account Inventory Template · NHI Governance Maturity Model