Identity Programme Roadmap Template

Identity programmes stall when they are run as a sequence of tool projects with no agreed target state, no business owners and no measure of progress. This template gives you a three-year roadmap document you can complete and take to a steering committee. It covers scope, governance, a baseline assessment, the target state, a phased plan across workforce, privileged, customer and non-human identities, metrics, dependencies and review. Replace the bracketed text, keep the sections that apply, and use the example milestones as a starting point rather than a fixed plan. For the programme design behind it see the Identity Security Programme Guide.

How to use this template

Replace text in square brackets, such as [Organisation], [Programme sponsor] and [Year 1], with your own terms and dates.
Complete Section 3 (baseline) before Sections 5 to 7. The phases only make sense against a measured starting point.
Each milestone in Sections 5 to 7 should have an owner, a target quarter and a measurable exit criterion. Delete examples that do not apply.
"Must" marks commitments the steering committee is asked to approve; "should" marks recommended practice that can be deferred with a recorded reason.
Keep the roadmap to a version-controlled document reviewed every quarter (Section 10). A roadmap that is not revisited becomes a wish list.
Treat it as a business programme, not an IT project. IDPro's Body of Knowledge makes the point that authorisations belong to process and data owners, with IT providing the tooling.

1. Purpose and scope

This roadmap sets out how [Organisation] will improve the security, efficiency and assurance of identity and access over [Year 1] to [Year 3]. It covers:

Workforce identities: employees, contractors and partners in [list directories and IdPs].
Privileged identities: administrative accounts, break-glass accounts and privileged roles in [on-premises and cloud platforms].
Non-human identities: service accounts, API keys, OAuth applications, certificates, workload identities and AI agents.
Customer identities: [include or exclude; if included, list the customer-facing platforms].

Out of scope: [for example physical access control, HR system replacement]. Interfaces with those programmes are listed in Section 9.

2. Governance and roles

Role	Named person	Responsibilities
Programme sponsor	[Name, title]	Owns the outcomes, chairs the steering committee, secures funding
Programme lead	[Name]	Runs the roadmap, reports progress, manages dependencies and risks
Identity architect	[Name]	Target state, standards, technical design authority
Business process and data owners	[Names per function]	Define and approve access rules, roles and segregation of duties; certify access
HR representative	[Name]	Authoritative source for joiner, mover and leaver events
NHI owners	[Application and platform owners]	Accountable for each service account, key and integration in their systems
Security operations	[Name]	Identity detection and response requirements and use cases
Risk, audit and privacy	[Names]	Assurance requirements, control testing, data protection review

The steering committee meets [monthly]. Decisions, risk acceptances and changes to scope must be recorded in the programme decision log. This supports NIST CSF 2.0 outcome GV.RR-02 (roles, responsibilities and authorities established and enforced).

3. Baseline assessment

Record the current position for each capability, with the evidence used. Score against the maturity model the organisation already uses, for example the Identity Security Maturity Model, the NHI Governance Maturity Model or the NSA's zero trust user pillar phases (Preparation, Basic, Intermediate, Advanced).

Capability	Current state [evidence]	Score now	Target by [Year 3]
Identity inventory and authoritative sources	[e.g. HR feeds two of five directories]	[ ]	[ ]
Authentication and MFA coverage	[e.g. 92% of users, SMS fallback]	[ ]	[ ]
Joiner, mover, leaver automation	[e.g. leaver SLA 5 days, manual for SaaS]	[ ]	[ ]
Access governance and reviews	[ ]	[ ]	[ ]
Privileged access	[ ]	[ ]	[ ]
Non-human identity inventory and ownership	[ ]	[ ]	[ ]
Secrets and certificate management	[ ]	[ ]	[ ]
Identity threat detection and response	[ ]	[ ]	[ ]
Customer identity (if in scope)	[ ]	[ ]	[ ]

List the top five identity risks found, each with a reference to the risk register: [Risk 1] ... [Risk 5].

4. Target state and principles

By the end of [Year 3], [Organisation] will:

Have one authoritative record for every human and non-human identity, each with a named owner.
Use phishing-resistant authentication for all privileged users and [all / most] workforce users.
Grant, change and remove access automatically from HR and application events, with leavers removed within [4 hours] in core systems.
Hold no standing privileged access except documented break-glass accounts.
Know the owner, purpose, scope and expiry of every service account, key, token, certificate and AI agent.
Detect and respond to identity attacks using identity-specific detections and playbooks.

Design principles: [for example, buy before build; standards-based integration (SAML, OIDC, SCIM); least privilege by default; every exception expires].

5. Year 1: Foundations

Workstream	Milestone	Owner	Quarter	Exit criterion
Authentication	MFA on all remote access, email and admin portals; phishing-resistant MFA for administrators	[ ]	[Q1-Q2]	100% admins on FIDO2 or certificate-based MFA
Privileged access	Inventory privileged accounts; separate admin accounts; vault break-glass credentials	[ ]	[Q2]	No daily-use account holds admin roles
Lifecycle	HR as authoritative source; automated leaver for directory and top [20] apps	[ ]	[Q3]	Leaver SLA met for 95% of events
NHI	Discover service accounts, keys and OAuth apps in [main platforms]; assign owners	[ ]	[Q2-Q4]	80% of discovered NHIs have an owner
Detection	Identity logs (IdP, directory, PAM) in the SIEM with core detections	[ ]	[Q3]	Detections for MFA fatigue, impossible travel, new admin assignment live
Governance	Approve identity policy; first access review of privileged and finance roles	[ ]	[Q4]	Review completed with revocations actioned

See the Joiner-Mover-Leaver Guide and the Privileged Access Management Guide.

6. Year 2: Expansion

Workstream	Milestone	Owner	Quarter	Exit criterion
Authentication	Passkeys or phishing-resistant MFA for the general workforce; remove SMS and voice fallback	[ ]	[ ]	[90]% of users on phishing-resistant methods
Governance	Onboard [50] applications to IGA with entitlement catalogue and owners; role model for top functions	[ ]	[ ]	Quarterly reviews run from IGA, not spreadsheets
Privileged access	Just-in-time elevation for cloud and directory admin roles	[ ]	[ ]	Standing admin assignments reduced by [80]%
NHI	Move secrets to a vault; rotate or replace long-lived keys; adopt workload identity federation for CI/CD	[ ]	[ ]	No static cloud keys in pipelines
SaaS	Restrict OAuth consent; inventory and review third-party grants	[ ]	[ ]	High-risk grants reviewed quarterly
Detection	Identity threat detection and response playbooks for account takeover and token theft	[ ]	[ ]	Playbooks tested in an exercise

7. Year 3: Optimisation

Risk-based access: device and session risk signals feed access decisions and continuous evaluation, matching the NSA user pillar's Advanced phase (risk-based attributes, granular per-resource access, behaviour analysis).
Policy-based authorisation: fine-grained, attribute-based decisions for [priority applications].
NHI lifecycle: every NHI created through a governed request with owner, scope and expiry; automatic decommissioning of unused identities.
AI agents: agents registered as identities with delegated, scoped and logged access. See the Identity Governance for AI Agents Guide.
Continuous assurance: automated control evidence for audit; access reviews targeted by risk rather than calendar.

Record Year 3 milestones in the same table format as Sections 5 and 6.

8. Metrics and reporting

Metric	Baseline	Year 1	Year 2	Year 3
Users on phishing-resistant authentication (%)	[ ]	[ ]	[ ]	[ ]
Leaver access removed within SLA (%)	[ ]	[ ]	[ ]	[ ]
Standing privileged assignments (count)	[ ]	[ ]	[ ]	[ ]
NHIs with a named owner (%)	[ ]	[ ]	[ ]	[ ]
Applications integrated with SSO and lifecycle (%)	[ ]	[ ]	[ ]	[ ]
Access review revocation rate and completion (%)	[ ]	[ ]	[ ]	[ ]
Mean time to contain identity incidents (hours)	[ ]	[ ]	[ ]	[ ]

Report to the steering committee [monthly] and to [the board or risk committee] [quarterly], using the same metrics each time.

9. Dependencies, risks and funding

Dependencies: [HR data quality project], [endpoint management rollout for device signals], [network or VPN replacement], [application owners' capacity to onboard].
Programme risks: [for example, business owners unavailable for role design; licence costs; legacy apps without SSO or SCIM]. Each risk must have an owner and a mitigation.
Funding: [capital and operating cost per year; staffing plan]. Link the case to measurable risk reduction; see the Business Case Guide.
Skills: [identity engineering, IGA administration, PKI, detection engineering]; record training and hiring needs.

10. Review and change control

The programme lead must review progress against milestones and metrics [quarterly] and propose changes.
Changes to scope, target state or funding must be approved by the steering committee and recorded in the decision log.
The roadmap must be fully refreshed [annually], including a new baseline score, which supports CSF 2.0 GV.OV-01 (strategy outcomes reviewed to adjust direction) and ID.IM-01 (improvements identified from evaluations).
Version: [1.0]. Owner: [Programme lead]. Approved by: [Sponsor]. Next review: [date].

Implementation guidance

Start with the baseline, not the tools: interview owners, pull metrics from the IdP, directory, PAM and HR systems, and score Section 3 with evidence. Two to four weeks is typical.
Prioritise by risk: privileged access, phishing-resistant MFA for admins and leaver automation usually reduce the most risk first. NHI discovery should start in Year 1 because ownership takes longest to establish.
Name business owners early: IDPro's guidance warns against creating roles or rules nobody owns. Do not build a role model until each role has an accountable owner.
Size the roadmap to capacity: a small organisation may compress Years 1 and 2 into one year with a single IdP and few apps; a large one may need regional or business-unit waves within each year.
Pilot each change: roll out authentication and lifecycle changes to a pilot group, measure helpdesk impact, then expand in rings, with a documented rollback (for example, re-enabling a previous authentication method for a group).
Plan communications with each phase: users notice authentication changes, managers notice access reviews and application owners notice NHI ownership requests. Publish what changes, when, why and where to get help at least two weeks before each wave, and brief the service desk first so it can handle the first day's calls.
Do not leave non-human identities to the end: service accounts and integration tokens usually outnumber people many times over and often hold more privilege. Start discovery in Year 1, even if remediation runs into Year 2, and make ownership a condition of keeping the credential. See the NHI Governance Maturity Model.
Agree what "done" means for each milestone: write the exit criterion before work starts and have risk or audit confirm it at the end, so the committee is approving evidence rather than status reports.
Report outcomes, not activity: the metrics in Section 8 should move each quarter; if they do not, change the plan.