Identity and Access Management Roadmap: 12-Month Template With Owners

9 min read · 2026-10-25

An identity and access management roadmap is a phased plan that moves your company from scattered accounts and manual access requests to one identity source, single sign-on, strong authentication, automated provisioning and regular access reviews. It tells security, IT and HR what gets done in which order, who owns each step and how you will prove progress to leadership and auditors.

The template below covers 12 months in six phases for workforce identity, meaning employees and contractors. Each phase ends with a milestone you can check. After the plan you get a filled-in example for a growing software company, a roles list, the metrics to report, how to present the roadmap to leadership and the mistakes that stall IAM programs halfway.

The roadmap at a glance

Goal: Every in-scope workforce application uses single sign-on and MFA, accounts are created and removed from HR events, privileged access is controlled, and access is reviewed every quarter. Duration: 12 months

1. Discovery and current state (Weeks 1-6)

   Know which identities, applications and access paths you actually have.

   • Build an application inventory with owner, number of users, login method and data sensitivity for each app.
   • Map how a new hire, a role change and a leaver are handled today, step by step, with who does what.
   • List all identity stores in use, such as Active Directory, a cloud directory and local app accounts.
   • Pull a sample of leaver accounts and check how many were still active after the last working day.
   • Interview HR, IT service desk, security and two or three app owners about their main pain points.

   Milestone: An application inventory and a current-state report with the top identity risks, reviewed by the CISO or IT director.

2. Strategy, design and governance (Weeks 7-10)

   Agree on the target design and how decisions will be made.

   • Choose the authoritative source of identity, usually the HR system, and the main identity provider.
   • Define the target state for authentication, provisioning, privileged access and access reviews.
   • Group applications into waves by risk, user count and how easy they are to connect.
   • Set up an IAM steering group with security, IT, HR and a business representative.
   • Write the access policy basics: who approves access, how often it is reviewed, and how exceptions are handled.

   Milestone: Target architecture, application waves and access policy approved by the steering group.

3. SSO and MFA foundation (Weeks 11-22)

   Put the most used and most sensitive apps behind one login with strong authentication.

   • Connect the first wave of applications to the identity provider using SAML or OpenID Connect.
   • Roll out MFA to all users, starting with admins and remote access, and prefer phishing-resistant methods such as security keys or passkeys where possible.
   • Turn off legacy authentication protocols that cannot do MFA, after checking which apps still use them.
   • Publish short user guides and train the service desk on enrollment and lost-device cases.

   Milestone: First-wave apps on SSO, MFA enforced for all users, and legacy authentication blocked for connected apps.

4. Lifecycle automation (Weeks 23-34)

   Create, change and remove access automatically from HR events.

   • Connect the HR system to the identity provider so hires, transfers and leavers trigger changes automatically.
   • Define birthright access per department and role, such as email, chat and the intranet.
   • Turn on automated provisioning (for example SCIM) for apps that support it, and write manual runbooks for those that do not.
   • Test the leaver flow end to end, including same-day removal for involuntary exits.

   Milestone: Joiner, mover and leaver flows automated for the HR source and the first wave of apps, with test evidence on file.

5. Privileged access (Weeks 35-44)

   Control and record the accounts that can do the most damage.

   • Inventory privileged accounts: domain admins, cloud admins, database admins, service accounts and shared accounts.
   • Move admins to separate admin accounts and remove standing admin rights where you can.
   • Store shared and service account credentials in a vault and rotate them.
   • Add approval and time limits for elevated access, with session logs for the most critical systems.

   Milestone: All known privileged accounts inventoried, vaulted or assigned to a named owner, with no shared admin passwords in use.

6. Access reviews and continuous improvement (Weeks 45-52)

   Prove that access stays right over time.

   • Run the first quarterly access review for sensitive apps, with managers and app owners confirming or removing access.
   • Track removals that come out of the review and close them within an agreed time.
   • Connect the second wave of applications to SSO and provisioning.
   • Draft next year's roadmap, for example role-based access, customer identity or non-human identities.

   Milestone: First access review completed with all removals closed, and next year's roadmap approved by the steering group.

Common mistakes to avoid

• Starting with a tool purchase before you know your apps leads to gaps you find too late, so build the application inventory first.
• Rolling out MFA without preparing the service desk floods it with lockouts, so train the desk and publish enrollment guides before you enforce.
• Automating provisioning on top of messy HR data spreads errors to every app, so clean job titles, departments and manager fields first.
• Leaving legacy authentication on after MFA rollout leaves a back door open, so find and block legacy protocols for connected apps.
• Making the IAM team decide who should have access overloads it and slows reviews, so make app owners and managers accountable for access decisions.
• Treating service accounts as an afterthought leaves powerful credentials unmanaged, so include them in the privileged access inventory and give each one an owner.

Frequently asked questions

What should an IAM roadmap include?

It should include an application and identity inventory, the target design, SSO and MFA rollout, joiner, mover and leaver automation, privileged access management and access reviews. Each phase needs an owner, a milestone and a metric. Add governance so decisions about access have a clear home.

How long does an IAM implementation take?

It depends on the number of apps, the state of HR data and how many teams are involved. Many companies get core SSO, MFA and leaver automation in place within a year. Full coverage of every app and role-based access often takes longer and runs in waves.

What comes first, SSO or MFA?

Many teams do them together, because connecting apps to one identity provider lets you enforce MFA in one place. If you must pick, enforce MFA first on email, remote access and admin accounts, since those are common targets. Then bring other apps under SSO so they inherit the same protection.

Who should own identity and access management?

Usually security or IT owns the IAM program, with an IAM lead running the roadmap. HR owns the identity data, and app owners own decisions about who gets access to their app. A steering group with all of them keeps the program moving.

What is the NIST identity and access management roadmap?

NIST publishes an IAM roadmap that lists planned milestones for its own identity guidance, such as the Digital Identity Guidelines (SP 800-63) and the PIV standard for federal credentials. It is useful background, but it is not a project plan for a company. Use the guidance it points to when you shape your target design, and build your own phased roadmap like the one above.

Generate this roadmap with AI