Phase Identity Programmes for Evidence in 6 Months, Not Slideware

The first six months decide whether identity becomes evidence or theatre

A surprising number of identity programmes spend month one producing a steering committee deck, month two writing a target-state diagram, and month six still arguing about attribute sources. By then, the business has paid for workshops, but the audit team still cannot see a measurable reduction in standing access or phishing exposure.

The contrarian truth: identity is not a strategy problem first; it is a sequencing problem. If you phase the programme correctly, the first 180 days can produce hard evidence: fewer privileged accounts, faster joiner-mover-leaver handling, better MFA coverage, and logs that prove who got access, when, and why.

Start with one measurable outcome, not a platform shortlist

If you try to modernise SSO, MFA, lifecycle management, PAM, IGA, and machine identity at once, you will create a dependency graph that nobody can fund or deliver. Pick one outcome that a CTO, CISO, and audit lead all care about, then build the programme around that outcome.

A good first outcome looks like this:

• Reduce standing privileged access by 40% in 90 days.
• Cut joiner provisioning from 3 days to under 4 hours for one business unit.
• Reach 95% phishing-resistant MFA coverage for administrators and developers.
• Produce quarterly evidence packs automatically from identity logs.

Choose a control plane before you choose every product

The control plane is the combination of directory, policy, authentication, provisioning, and logging that becomes the source of truth. In 2026, that usually means one of three patterns:

• Cloud-first: Microsoft Entra ID or Okta as the primary control plane.
• Hybrid: Entra ID plus Active Directory for legacy workloads.
• Regulated multi-domain: central IdP with delegated admin and segmented policy boundaries.

Do not start by replacing everything. Start by deciding where policy lives, where identity proofing happens, and where logs are retained. If your control plane cannot emit clean events to SIEM, GRC, and data lake systems, you do not have an identity programme; you have a login project.

Identity control plane for phase 1

HR system -> Identity workflow engine -> Directory / IdP -> SaaS apps
                     |                      |                |
                     |                      |                +--> Audit logs -> SIEM -> Evidence store
                     |                      +--> MFA / Conditional Access
                     +--> Joiner-mover-leaver rules

Phase 1: Days 1-30, build the evidence baseline

The first month is not about rollout velocity. It is about establishing a baseline that you can defend in front of finance, security, and internal audit.

Inventory what actually exists

Most enterprises think they have 12 critical apps and discover 47 when they map SSO, local accounts, and service credentials. Start with a controlled inventory:

• Top 20 business applications by user count.
• All privileged roles in cloud, endpoint, database, and network systems.
• All identity sources: HR, contractor system, IAM directory, partner directory.
• All authentication methods in use: passwords, push MFA, FIDO2, device certificates, passkeys.

A realistic baseline exercise for a 10,000-user enterprise usually takes 2 to 3 weeks and exposes 15% to 25% duplicate or stale accounts. In one manufacturing rollout, the first discovery pass found 1,840 local admin accounts across 430 endpoints, with 31% unused for more than 90 days.

Establish three metrics you can track weekly

Use metrics that show operational movement, not vanity counts.

1. Standing privileged accounts: number of permanent admin assignments.
2. Provisioning SLA: median time from HR event to usable access.
3. Phishing-resistant MFA coverage: percentage of admin and developer accounts using FIDO2, passkeys, or certificate-based auth.

A good baseline dashboard uses weekly trend lines and a red/amber/green threshold. Example targets for month one:

• Standing privileged accounts: baseline only.
• Provisioning SLA: baseline only.
• Phishing-resistant MFA: 18% admin coverage, 6% developer coverage in many enterprises before phase 1.

Instrument the logs before you change policy

If you do not capture the current state, every later improvement becomes anecdotal. Configure your IdP, directory, PAM, and HR workflow logs to land in a central store with at least 180 days of retention.

# Example: identity telemetry pipeline
sources:
  - microsoft-entra-signin
  - okta-system-log
  - active-directory-security
  - pam-session-records
  - hris-events
sinks:
  - siem
  - data-lake
  - evidence-vault
retention_days: 180
required_fields:
  - user_id
  - actor_id
  - event_type
  - timestamp_utc
  - resource_id
  - approval_id
  - device_trust_state

Phase 2: Days 31-90, prove one production path end to end

This is where many programmes drift into slideware. They announce a target architecture, then distribute work across every domain. Resist that urge. Pick one production path and make it boringly reliable.

A strong pilot path has four properties

• High business value.
• Moderate complexity.
• Visible audit value.
• Clear ownership.

The best pilot is often one of these:

• New employee access for a single business unit.
• Privileged access for cloud engineers.
• Contractor onboarding for one vendor population.
• Access to a regulated application with weak current controls.

Example: cloud engineering privileged access

Suppose your platform team has 120 engineers and 40 permanent admin entitlements across Kubernetes, AWS, and GitHub. Phase 2 should move them to just-in-time access with approval, session logging, and expiry.

A realistic outcome after 60 days:

• Permanent admin roles reduced from 40 to 11.
• 92% of privileged sessions recorded.
• Mean approval time: 14 minutes during business hours.
• Break-glass usage: 3 events, all reviewed within 24 hours.

{
  "role": "cloud-platform-admin",
  "grant_type": "just-in-time",
  "approval_required": true,
  "max_duration_minutes": 60,
  "session_recording": true,
  "ticket_required": true,
  "auto_revoke_on_expiry": true
}

Make the workflow visible to the business

Show the before-and-after path in a way that non-specialists understand.

Before:
Manager email -> IT ticket -> manual group change -> local admin grant -> no expiry

After:
HR event -> workflow -> policy check -> approver -> IdP group -> PAM session -> log export -> evidence pack

That shift matters because it turns identity from a hidden operations cost into a measurable control. In a regulated financial services deployment, this kind of workflow cut privileged access exceptions by 58% in one quarter and reduced audit evidence collection from 4 days to 90 minutes.

Phase 3: Days 91-180, expand by control pattern, not by app count

By month four, the temptation is to chase coverage numbers. Do not expand randomly. Expand by repeating a control pattern that already works.

Use control patterns that scale

A control pattern is a reusable set of rules, integrations, and evidence outputs. The most useful patterns in 2026 are:

• Phishing-resistant MFA for admins and developers.
• Joiner-mover-leaver automation for employees and contractors.
• JIT privileged elevation with session recording.
• Access certification for high-risk apps and data sets.
• Machine identity issuance and rotation for workloads and APIs.

Each pattern should have a named owner, a standard workflow, and a measurable SLA. For example:

• Joiner access: 95% provisioned within 4 hours.
• Mover changes: 90% completed within 24 hours.
• Leaver revocation: 99% completed within 15 minutes for SaaS and cloud access.
• Privileged session logging: 98% completeness.

Build evidence packs automatically

The point of phase 3 is not just better control; it is repeatable proof. Evidence packs should be generated from logs, workflow state, and approval records, not assembled manually from screenshots.

A practical evidence pack includes:

• Access request ID and approver.
• Policy version in force at approval time.
• MFA method used.
• Session recording reference.
• Revocation timestamp.
• Exception expiry date, if any.

# Example: simple evidence extraction logic
import json

def build_evidence(event):
    return {
        "user": event["user_id"],
        "resource": event["resource_id"],
        "approved_by": event.get("approval_id"),
        "mfa": event.get("auth_method"),
        "granted_at": event["timestamp_utc"],
        "expires_at": event.get("expiry_utc"),
        "ticket": event.get("ticket_id")
    }

Common Pitfalls

The same mistakes appear in almost every stalled identity programme.

1. Buying tooling before defining evidence

If the business cannot name the evidence it wants, the project will default to feature comparisons. Avoid this by writing three evidence questions first: who got access, who approved it, and when it was removed.

2. Trying to fix every directory at once

Many enterprises have Active Directory, Entra ID, LDAP, local app stores, and shadow directories in SaaS tools. Start with the highest-risk path and leave low-value cleanup for later.

3. Treating MFA as the finish line

Push MFA is better than passwords, but in 2026 it is not enough for privileged users. Move admins and developers to passkeys, FIDO2 security keys, or certificate-backed auth where feasible.

4. Ignoring service and machine identities

Some programmes reduce human risk while leaving thousands of unmanaged API keys and workload credentials untouched. In one retail environment, machine secrets outnumbered human identities 14:1. That ratio made human-focused controls look better than they were.

5. Measuring activity instead of control

Counting workshops, integrations, or policy drafts tells you almost nothing. Count revoked access, reduced standing privilege, shorter SLA times, and evidence pack generation time.

What good looks like by day 180

By the end of six months, a credible identity programme should show visible operational change. For a 10,000-user enterprise, a realistic target set looks like this:

• 30% to 50% reduction in standing privileged access.
• 80% to 90% of new joiners provisioned within 4 hours for the pilot population.
• 95% MFA coverage for privileged users, with at least 70% on phishing-resistant methods.
• 90%+ of privileged sessions logged and retained.
• Audit evidence produced in under 2 hours for the pilot scope.

These numbers are not aspirational. They are achievable when the programme is phased around one production path and one reporting loop. They also create budget credibility, because the business can see that identity is reducing risk and operational drag at the same time.

Key Takeaways

• Pick one measurable outcome for the first 180 days, such as reducing standing privilege or cutting provisioning time.
• Build a baseline in the first 30 days and instrument logs before you change policy.
• Prove one production path end to end before expanding to more apps or more business units.
• Expand by repeating control patterns: JIT access, phishing-resistant MFA, JML automation, and evidence packs.
• Measure control outcomes weekly: revoked access, SLA times, MFA coverage, and log completeness.
• Treat evidence as a product output, not a manual audit task.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.