When identity and access management projects stall at growing companies, the cause is usually sequence rather than technology. Teams buy a good identity provider, switch on MFA for everyone on a Monday, and spend the next month handling lockouts while three admin accounts with permanent global rights sit untouched. The tools were fine. The order was wrong.
Identity is the first phase in our Zero Trust architecture implementation roadmap, and this article goes one level deeper. It covers the order we’d follow for a company that’s outgrown “everyone has a Google or Microsoft account and we’ll sort the rest later”: inventory, identity provider consolidation, SSO, MFA, conditional access, privileged identity management, and joiner-mover-leaver automation. Each step has a metric so you can tell whether it’s working.
Identity and access management implementation steps, in order
If you only take one thing from this article, take the order. Each step makes the next one cheaper.
- Inventory every identity, human and non-human, and every app that holds its own user list.
- Consolidate onto one cloud identity provider as the source of truth for workforce accounts.
- Put applications behind SSO, starting with the ones that hold sensitive data.
- Roll out MFA, with phishing-resistant methods for admins and high-risk users first.
- Add conditional access policies that factor in device health, location and risk.
- Move admin rights into privileged identity management with just-in-time elevation.
- Automate the joiner-mover-leaver process so access follows HR changes without tickets getting lost.
You can overlap steps. You shouldn’t skip them. Running MFA before SSO means users enrol in five different MFA systems. Adding PIM before you’ve consolidated identities means you’re protecting admin roles in one directory while shadow admins live in another.
Start with an identity inventory and one cloud identity provider
Before you configure anything, find out what you have. You’re looking for:
- Every directory: on-premise Active Directory, cloud directories, and any HR system that creates accounts
- Every SaaS app with local usernames and passwords rather than SSO
- Service accounts, API keys and shared mailboxes (non-human identities are the easiest to forget)
- Accounts belonging to people who have left
That last list is usually the uncomfortable one. It’s also the most useful, because every orphaned account is an entry point nobody is watching.
Then pick one cloud identity provider (IdP) as the authority for workforce identity. For most growing companies that’s the directory attached to their productivity suite, because it already has every employee in it. Hybrid setups can keep on-premise Active Directory for legacy systems and sync into the cloud IdP, but the cloud side should become where policies live.
This is where a lot of mid-size teams stall. The design isn’t hard, but the migration work is tedious and it competes with every other IT priority. SecureShield, our managed Zero Trust service, includes a cloud IdP with SSO, MFA and privileged identity management as listed modules, and we run the implementation end to end so the consolidation work doesn’t sit in someone’s backlog for two quarters.
SSO implementation: connect apps by risk, not alphabetically
Single sign-on means users authenticate once to the IdP and reach connected applications without separate passwords. The security benefit is concentration: one place to enforce MFA, one place to disable an account, one sign-in log to watch.
Order the app backlog by what’s at stake:
- Email and file storage
- Finance, payroll and HR systems
- Remote access, VPN and admin consoles
- Customer data platforms such as CRM and support tools
- Everything else, in order of user count
Prefer SAML or OpenID Connect integrations. Where an app only supports password vaulting, treat that as a stopgap and flag the app for replacement at renewal. And turn off local login wherever the app allows it. SSO that users can bypass with an old password isn’t doing its job.
MFA rollout: go phishing-resistant where it counts
Not all MFA is equal, and the standards bodies are now explicit about it. NIST’s SP 800-63B-4, finalised in 2025, states that passwords, one-time codes, out-of-band devices and look-up secrets are not phishing-resistant. Only cryptographic authenticators meeting its additional requirements are. At its middle assurance level (AAL2), verifiers must offer at least one phishing-resistant option, and at AAL3 phishing resistance is required.
CISA’s fact sheet on implementing phishing-resistant MFA is blunter. It names FIDO/WebAuthn and PKI-based MFA as the phishing-resistant options, calls SMS and voice codes a last resort, and warns that push notifications without number matching are open to push-bombing.
Here’s how we’d phase an MFA rollout:
- Admins and IT staff get FIDO2 security keys or platform passkeys first. No exceptions.
- Executives, finance and anyone who can approve payments come next, also on phishing-resistant methods.
- Everyone else moves to an authenticator app with number matching, with passkeys offered as the default where devices support them.
- SMS stays only as a documented fallback for specific cases, with an end date.
Communicate before you enforce. Give people a two-week enrolment window with reminders, then enforce by group. The lockout storm happens when enforcement and enrolment land on the same day.
Conditional access, device compliance and least privilege
MFA answers “is this the right person?” Conditional access asks the follow-up questions: from what device, from where, and how risky does this sign-in look? Policies might require a compliant, managed device to open finance apps, block legacy authentication protocols entirely, or demand step-up authentication when a sign-in comes from a new country.
This is the Zero Trust model working as intended. NIST SP 800-207 describes authentication and authorisation of both subject and device as discrete functions performed before a session to a resource is established. Conditional access is how most organisations implement that in practice.
Two dependencies make it work. First, device compliance data has to be trustworthy, which means devices need to be enrolled in management. Our guide to endpoint MDM and device security covers how to get there. Second, sign-in logs need to go somewhere people look. Identity signals such as impossible travel, repeated MFA failures and new admin role assignments are among the most useful inputs to threat detection, which we cover in our post on SIEM and managed detection and response.
Start conditional access in report-only mode for a week or two. You’ll find the service accounts and old scanners that would have broken, and you can fix them before users notice.
Privileged identity management: lock down admin access
Standing admin rights are what an intruder wants most. An attacker who phishes a global administrator doesn’t need to escalate privileges. They already have them.
Privileged identity management (PIM) removes that standing access. Admins hold eligible roles rather than active ones and elevate when they need to, for a limited window, often with an approval step, a justification and a fresh MFA prompt. Every elevation is logged. CISA’s Zero Trust Maturity Model describes its Optimal stage in terms of “fully automated, just-in-time lifecycles” and dynamic least privilege. For identity access management specifically, Optimal means using automation “to authorize just-in-time and just-enough access tailored to individual actions and individual resource needs.” PIM is the most direct way to move admin accounts toward that.
A practical PIM rollout:
- List every privileged role in your IdP and cloud platforms, and who holds it.
- Cut the list. Many companies have more global admins than they need.
- Keep two emergency “break-glass” accounts with strong credentials, excluded from normal conditional access policies, with credentials stored offline and monitored for any use.
- Convert everyone else to eligible assignments with time-limited activation.
- Review assignments quarterly and remove anyone who hasn’t elevated in that period.
PIM vs PAM
The terms overlap and vendors use them loosely. PIM usually refers to just-in-time control of roles inside an identity platform or cloud tenant. Privileged access management (PAM) is broader: credential vaulting for servers and databases, session recording, and control of shared or service accounts. A growing enterprise with mostly cloud workloads can often start with PIM in its IdP. Heavy on-premise infrastructure usually needs PAM too.
Automate the joiner-mover-leaver process
Joiner-mover-leaver (JML) is where access control lives or dies. Joiners need the right access on day one. Movers need old access removed when they change teams, which is the step most often skipped. Leavers need everything revoked the moment they go, including SaaS apps outside SSO.
The durable fix is to make the HR system the trigger. A hire, a transfer or a termination in HR creates, changes or disables the identity in the IdP, and group membership drives app access from there. Access that doesn’t map to a role goes through a request with an approver and an expiry date.
Requests and exceptions still land on a helpdesk, so the helpdesk should be part of the design. SupportDesk handles IT and HR support workflows with SLA tiers and RBAC, and it supports SSO/SAML, so the service desk itself sits behind your identity provider rather than becoming another island of local passwords. Our IT consulting and cyber security team designs the IAM side of this: role models, provisioning flows and the policies that connect them.
How to measure IAM progress at each step
An IAM roadmap without metrics turns into a list of tickets. Track one number per step and review it monthly. The targets are our starting points:
- Inventory: track accounts with no identified owner. Target: falling every month, then zero.
- IdP consolidation: track the share of workforce accounts mastered in the cloud IdP. Target: all active employees and contractors.
- SSO: track the share of business apps behind SSO, weighted by sensitivity. Target: all sensitive apps, local login disabled.
- MFA: track the share of users on phishing-resistant MFA, with admins tracked separately. Target: every admin, then high-risk groups.
- Conditional access: track sign-ins using legacy authentication. Target: zero.
- PIM: track standing privileged role assignments. Target: break-glass accounts only.
- JML: track time from HR termination to account disabled. Target: same working day, automated.
These are targets we’d set for a typical growing company, not industry benchmarks. Adjust them to your risk appetite and regulatory obligations.
Frequently asked questions
How do you implement SSO and MFA together?
Consolidate identities into one cloud identity provider first, then connect your highest-risk apps to it with SAML or OpenID Connect. Enforce MFA at the identity provider rather than inside each app, so users enrol once. Roll MFA out in waves, starting with admins on phishing-resistant methods, and disable local app logins so nobody can bypass SSO with an old password.
What does an IAM roadmap for a mid-size company look like?
A practical IAM roadmap runs in this order: identity inventory, consolidation onto one cloud identity provider, SSO for sensitive apps, MFA with phishing-resistant methods for admins, conditional access based on device and risk, privileged identity management for admin roles, then joiner-mover-leaver automation driven by HR. Track one metric per step so progress is visible to leadership.
What is the difference between PIM and PAM?
PIM usually means just-in-time activation of privileged roles inside an identity platform or cloud tenant, with approval, time limits and logging. PAM is broader and covers credential vaulting for servers and databases, session recording and control of shared or service accounts. Cloud-first companies can often start with PIM, while organisations with heavy on-premise infrastructure typically need PAM as well.
Is SMS-based MFA still acceptable?
It’s better than a password alone, but it’s the weakest option. NIST SP 800-63B-4 treats the phone network for out-of-band codes as a restricted authenticator, and CISA recommends SMS and voice only as a last resort because of phishing, SIM swap and SS7 risks. Keep it as a documented fallback with an end date, not as your default method.
What is least privilege in identity and access management?
Least privilege means each identity gets only the access its current role needs, for only as long as it needs it. In IAM that translates to role-based group membership, removing old access when people move teams, time-limited approvals for exceptions, and just-in-time elevation for admin rights instead of permanent assignments. Regular access reviews catch whatever drifts through the gaps.
How long does an IAM rollout take?
It depends on how many directories and applications you start with and how much migration work consolidation involves. Inventory and identity provider consolidation usually take the most effort, while SSO and MFA move faster once the foundation is in place. Plan in phases, measure one metric per step, and avoid enforcing MFA on the same day users are asked to enrol.
Start with an identity maturity check
Want to know where your identity setup stands today? Book an identity maturity assessment with us. We’ll map your directories, apps and admin accounts against this sequence and give you a prioritised plan for the next steps.