In what order should you add IAM jobs? A sequencing guide

Step 1: one identity provider

Every other job reads from a directory. Consolidating sign-in to one provider with phishing-resistant MFA comes first, because it touches every person every day. If you run Microsoft 365, Entra ID P1 may already be included in your plan.

Step 2: lifecycle from HR

Connect the HR system so that hires, moves and departures drive access changes automatically for connected applications. Many identity providers include basic lifecycle features: Okta's Core Essentials suite lists Lifecycle Management, and JumpCloud sells user lifecycle management as an add-on.

Step 3: reviews and evidence

When audits start, add access requests, access reviews and exportable evidence. This is where a governance product, inside your identity provider or beside it, earns its cost.

Step 4: privileged access

Inventory admin and service accounts, remove standing access where you can, and vault what remains. Heavy audit pressure or a large admin population moves this step earlier.

Step 5: the applications outside the connectors

Once governance runs, its blind spots show: applications with no connector, local accounts and custom-built applications. Organizations with many legacy or homegrown applications often need this step alongside step 3, because those applications are in audit scope from the start.

Step 6: detection on the identity layer

Start with what your identity provider includes for session risk. Add directory-focused detection if you still run Active Directory, and inline detection if legacy systems cannot take MFA.

Which signals change the order?

• Many legacy or custom-built applications: application coverage moves up.
• Regulated finance, DORA or NIS2: governance, privileged access and evidence move up together.
• Active Directory still in use: directory detection and recovery move up.
• An acquisition: application coverage moves up, because the acquired company's applications arrive unconnected. Orchid lists M&A and growth events among its use cases for this reason.

How do you avoid buying two tools for one job?

The stack map shows overlaps. Microsoft and Okta each document three jobs; adding a separate governance platform next to their governance products should be a deliberate choice, not an accident of two buying cycles.