KRIs for identity and access management

Attackers rarely break in anymore. They log in. The overwhelming majority of incidents begin with a compromised credential, an over-privileged account, or a conditional access gap, not a zero-day. That makes identity and access management the control surface where measurement matters most, because the difference between “we have MFA” and “MFA is enforced for 99% of accounts with no active bypass” is the difference between a real control and a risk acceptance nobody intended.

The KRIs below measure whether IAM functions as a genuine control or as a checkbox that looks complete on paper while leaving material credential exposure in practice. Each one is derived from data your identity provider, IGA, and PAM platforms already emit, so you can track enforcement continuously instead of reconstructing it before an audit. If you are standing up a measurement program from scratch, start with how to build a KRI program and treat this page as the IAM-domain detail.

These eight pair naturally with the operational signals in KRIs for security operations, the broader stack coverage in KRIs for enterprise security, and the build-pipeline view in KRIs for application security. The full catalog, with green, amber, and red thresholds mapped to CIS Controls, lives in the KRI reference library.

KRI inventory

Eight indicators cover the IAM control surface: enforcement, privilege, account hygiene, least privilege, non-human identity, identity threat detection, conditional access, and governance currency. Each has a clear derivation source and a green/amber/red band you can wire to an alert.

1. MFA enforcement rate

What to measure. Percentage of user accounts with active MFA enrollment and policy enforcement (not just the enrollment option being available), segmented by account type: standard users, privileged users, service accounts, and external or partner accounts.

Why it matters. Enrollment and enforcement are different things. A user can be enrolled in MFA and still reach email over a legacy protocol that bypasses it. Enforcement rate measures the control, not the option. Segmentation matters because a single un-enforced privileged account is a higher-risk gap than a hundred standard accounts.

• Identity provider (Microsoft Entra ID): Conditional Access policy scope, legacy authentication sign-in logs, per-user MFA status report
• Okta: MFA enrollment report, factor type distribution, legacy authentication usage report
• Google Workspace: 2-Step Verification enforcement status by OU
• Ping Identity or CyberArk Identity: policy enforcement scope
• Authentication logs: sign-in events with no MFA claim present, the most reliable enforcement-gap signal

How to calculate. Enrollment is (accounts with an MFA method registered) ÷ (total accounts) × 100. Enforcement is (accounts where every authentication path requires MFA) ÷ (total accounts) × 100, which requires checking that legacy auth is blocked. Track legacy auth sign-ins as a raw count of events using protocols that bypass MFA (IMAP, POP3, basic auth, SMTP auth).

Status	Criteria
Green	>99% standard users enforced; 100% privileged users enforced; zero legacy authentication sign-ins
Amber	90–98% standard users; or legacy auth sign-ins present at <100/day
Red	<90% standard users; or any privileged account without MFA; or >100 legacy auth sign-ins/day

2. Privileged access sprawl index

What to measure. Count of accounts with elevated permissions (admin, root, global admin, privileged roles) against a documented and approved baseline, combined with the rate of new privilege grants and the percentage of grants that went through a formal approval workflow.

Why it matters. Privileged accounts are the keys to the kingdom. Sprawl, meaning more privileged accounts than the baseline warrants, compounds risk because each privileged account is a potential lateral movement path to everything. Grants that bypass the approval workflow are both a process failure and an unreviewed risk acceptance. For a deeper treatment of standing privilege, vaulting, and session control, see the privileged access management guide.

• Microsoft Entra ID: Global Admins, Privileged Role Administrators, custom privileged roles, exported via Microsoft Graph or the Roles and Administrators blade
• Okta: Super Admin, Org Admin, and App Admin role assignments
• AWS IAM: users and roles with AdministratorAccess or PowerUserAccess; IAM Access Analyzer
• GCP IAM: project Owner and Editor bindings; organization-level roles
• PAM platforms (CyberArk, BeyondTrust, Delinea): vaulted account inventory against total privileged accounts
• Active Directory: Domain Admins, Enterprise Admins, and Schema Admins group membership

How to calculate. Sprawl is (current privileged account count) ÷ (approved baseline count) × 100, where anything above 100% is sprawl. Approval compliance is (privilege grants created via approved workflow) ÷ (total new grants) × 100. Also track standing versus just-in-time privilege: accounts with permanent privileged access against accounts using JIT or PIM access.

Status	Criteria
Green	At or below baseline; >95% of grants via approved workflow; >50% of privileged access is JIT
Amber	10–25% above baseline; or informal privilege grants under 10% of total
Red	>25% above baseline; or any undocumented global admin or root account; or most grants without an approval record

3. Dormant and orphaned account rate

What to measure. Percentage of accounts with active credentials that have had zero authentication activity in more than 90 days (dormant), and the count of accounts whose associated employee or service owner no longer exists in the HR system (orphaned).

Why it matters. Dormant accounts carry the persistent-access risk of departed employees, churned contractors, and unused service accounts. Orphaned accounts, where the owner is confirmed gone, are the highest-risk subset: active credentials with no accountability. These are the accounts threat actors reactivate because nobody is watching them.

• Identity provider last sign-in date per account (Entra ID lastSignInDateTime; Okta lastLogin; Google Workspace last active date)
• HR system (Workday, ADP, BambooHR): active roster cross-referenced against identity provider accounts for orphan detection
• Active Directory: lastLogonTimestamp on user objects (note the up-to-14-day replication lag)
• Service account registry: service accounts with no associated ticket or application record are orphaned
• PAM platform: vaulted credentials with no check-out activity in 90 days

How to calculate. Dormancy rate is (accounts with no auth activity in 90+ days) ÷ (total active accounts) × 100. Orphan rate is (accounts with no matching active HR record) ÷ (total accounts) × 100. Track high-risk orphans, the orphaned accounts that hold privileged access, as an absolute count.

Status	Criteria
Green	Dormancy <1%; orphan rate <0.5%; HR-triggered offboarding disables accounts within 24 hours
Amber	1–3% dormancy; or offboarding automation with >48 hour lag
Red	>3% dormancy; or any orphaned privileged account; or no automated offboarding process

4. Least privilege compliance rate

What to measure. Percentage of user accounts confirmed to hold only the permissions required for their current, documented role, verified through access certification (recertification) reviews.

Why it matters. Permission creep is universal and progressive. Users accumulate access through role changes, project assignments, emergency grants, and convenience, and permissions almost never get revoked. The result is a population with far broader access than intended, where one compromised credential reaches far more than it should. This rate measures whether your access model reflects reality.

• IGA platform (SailPoint IdentityNow, Saviynt, Omada): access certification campaign results, approved versus revoked entitlements per cycle
• Microsoft Entra ID Access Reviews: reviewer decisions on user-to-role and user-to-group assignments
• PAM platform: access review completion and findings
• Application-level access reviews: manual or IGA-automated certification of application entitlements
• RBAC audit: current permissions compared against approved role definitions

How to calculate. (Entitlements confirmed appropriate in the last access review cycle) ÷ (total entitlements reviewed) × 100. Track review completion separately: (accounts reviewed in the last cycle) ÷ (accounts in scope).

Status	Criteria
Green	>90% of privileged entitlements reviewed in the last 12 months; completion >95%; revocation within 48 hours of decision
Amber	70–89% reviewed; or completion <80%; or revocation lag >5 business days
Red	<70% reviewed; or no formal certification process; or entitlements approved without reviewer engagement

5. Service account and non-human identity risk rate

What to measure. Percentage of service accounts and non-human identities (API keys, service principals, machine identities, OAuth app grants) with documented owners, defined scope, credential rotation policies, and no excessive permissions.

Why it matters. Non-human identities now vastly outnumber human ones in most environments. They run applications, automation scripts, CI/CD pipelines, and integrations, and they are managed far less rigorously than human accounts. Long-lived credentials, over-permissioned service principals, and orphaned API keys are consistently among the most exploited identity attack vectors.

• Cloud IAM (AWS IAM, Entra ID App Registrations and Service Principals, GCP Service Accounts): non-human identity inventory with permission scope and last-activity date
• Secrets management (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault): API key inventory, rotation dates, and last-access logs
• GitHub or GitLab: machine tokens and deploy keys with their scopes and expiry dates
• CI/CD platforms: service connection and service account credentials in pipeline configurations
• PAM platform: service account vault coverage rate

How to calculate. (Service accounts with a documented owner, defined scope, active rotation policy, and confirmed least-privilege permissions) ÷ (total service accounts and non-human identities discovered) × 100.

Status	Criteria
Green	>90% of service accounts meet all four criteria; machine identity discovery runs continuously; API key rotation is enforced programmatically
Amber	70–89%; or rotation policy defined but not enforced; or discovery relying on manual inventory
Red	<70%; or any long-lived credential (over 1 year) with admin scope; or no service account inventory

6. Identity threat detection coverage

What to measure. Percentage of high-risk identity-based attack patterns (impossible travel, credential stuffing, privilege escalation, lateral movement via identity, token theft) covered by active detection rules with alerting.

Why it matters. Identity attacks are the most common initial-access and lateral-movement vector, and they need identity-specific detection. Network and endpoint tools frequently miss credential misuse that looks like normal user behavior from the application layer. Catching anomalous logins, impossible travel, excessive failed auth, and unusual privilege use requires telemetry from identity itself. For how trends in these signals serve as early warning, see reading the signal in drifting KRIs.

• Identity provider sign-in logs (Entra ID Sign-in Logs, Okta System Log, Google Workspace Admin Reports) fed into the SIEM for detection
• Microsoft Entra ID Protection risk detections (leaked credentials, anonymous IP, impossible travel, atypical travel, malware-linked IP)
• SIEM detection rules tagged with identity ATT&CK techniques (T1078 Valid Accounts, T1556 Modify Auth Process, T1110 Brute Force)
• UEBA platform (Microsoft Sentinel UEBA, Securonix, Exabeam): behavioral baseline and anomaly detection for identity

How to calculate. (High-risk identity attack patterns with active detection coverage) ÷ (total high-risk patterns in scope) × 100. Reference list: impossible travel, leaked credential alert, brute force detection, privilege escalation detection, anomalous application consent, and token theft indicators.

Status	Criteria
Green	All six core identity attack patterns covered; identity logs centrally ingested and retained 90+ days
Amber	4–5 of 6 core patterns covered; or identity logs ingested but not used for detection
Red	<4 patterns covered; or identity logs not ingested into the SIEM; or no identity-specific detection

7. Conditional access policy coverage

What to measure. Percentage of applications and access paths covered by Conditional Access (or equivalent risk-based access) policies, including policies that enforce MFA, block legacy auth, require compliant devices, and apply risk-based step-up authentication.

Why it matters. MFA enrollment means nothing if users can bypass it via legacy protocols or from unmanaged devices. Conditional Access is the enforcement layer that makes MFA and access controls real rather than optional. Coverage gaps are attack surfaces that are visible but uncontrolled.

• Microsoft Entra ID: Conditional Access policy inventory and the What If tool for testing coverage per user, app, and condition
• Okta: Adaptive MFA policies and per-application sign-on policy
• Google Workspace: context-aware access policies
• Third-party SSO (Ping, Duo, ForgeRock): policy coverage per application

How to calculate. Application coverage is (applications with a CA policy applied) ÷ (total applications in SSO scope) × 100. Legacy auth block is (accounts and applications with legacy protocols explicitly blocked) ÷ (total) × 100. Device compliance is (access paths requiring an Intune-compliant or Entra-joined device) ÷ (access paths to sensitive applications) × 100.

Status	Criteria
Green	100% of internet-accessible applications behind Conditional Access; legacy auth blocked; device compliance required for sensitive applications
Amber	Coverage gaps for legacy or non-SSO applications; or device compliance not enforced
Red	Conditional Access not implemented; or legacy auth universally allowed; or policy gaps for privileged access

8. Identity governance program currency

What to measure. Whether core identity governance processes (joiner/mover/leaver automation, access certification, role mining, segregation of duties review) are active, automated, and running on their defined cadence.

Why it matters. Identity governance is the operational discipline that keeps IAM controls current as the organization changes. Without it, infrastructure built correctly at one point drifts into accumulated exceptions, permission creep, and orphaned accounts. This KRI measures whether the machine is running, not just whether it was built.

• IGA platform (SailPoint, Saviynt, Omada): workflow execution logs for joiner/mover/leaver processes and certification campaign completion rates
• HR system integration: provisioning trigger latency, from HR hire date to account creation, and from HR termination to account disable
• Access certification records: last campaign completion date, completion rate, revocation rate
• SoD policy engine: last SoD review date and open violation count

How to calculate. JML automation coverage is (lifecycle events processed via automation) ÷ (total JML events) × 100. Also track termination-to-disable latency in hours from the HR termination trigger to account disable, access certification currency in days since the last completed cycle, and the absolute count of open SoD violations with no approved exception.

Status	Criteria
Green	>95% JML automation; termination-to-disable <4 hours and automated; certification completed in the last 6 months; <5 SoD violations, each with a documented exception
Amber	80–94% JML automation; or termination-to-disable 4–24 hours; or last certification 6–12 months ago
Red	<80% JML automation; or termination-to-disable >24 hours; or no certification in over 12 months

Deriving these KRIs by source type

The same indicator looks different depending on where the data comes from. These are the concrete queries and reports per platform. Auditors, regulators, insurers, and yes the board too will all ask for the resulting numbers, but the practitioner needs them first to know what is actually drifting.

From Microsoft Entra ID (Azure AD)

• MFA enforcement: GET /reports/authenticationMethods/userRegistrationDetails via MS Graph, filtered on isMfaRegistered, isMfaCapable, and methodsRegistered, cross-referenced with the Conditional Access “Require MFA” scope
• Legacy auth sign-ins: Entra Sign-in Logs filtered to clientAppUsed IN ("IMAP4", "POP3", "SMTP Auth", "Exchange ActiveSync", "Other clients"), counted per day for trending
• Privileged roles: GET /directoryRoles plus GET /directoryRoles/{id}/members for all PIM-eligible and active assignments
• Last sign-in: GET /users?$select=userPrincipalName,signInActivity, where lastSignInDateTime null or >90 days is a dormant candidate
• CA policy coverage: the Conditional Access What If tool, or export all policies and map them to the application inventory

The fastest way to wire this up is the Entra ID integration guide, which covers the Graph scopes and read-only roles Draxis needs.

From Okta

• MFA enrollment: System Log query eventType eq "system.mfa.factor.activate" for enrollment events, compared to total user count
• Legacy auth: factor type token:software:totp against password-only sign-ins in the System Log
• Last login: Users API GET /api/v1/users?filter=lastLogin lt "2024-01-01T00:00:00.000Z" for dormant detection
• Group membership for privilege sprawl: the Groups API, auditing membership against a documented privileged-group baseline

See the Okta integration guide for the API token scopes and read-only admin role to use.

From AWS IAM

• IAM Access Analyzer: aws accessanalyzer list-findings, where unused-access findings are a direct least-privilege signal
• Credential Report: aws iam generate-credential-report then aws iam get-credential-report for last-used dates, MFA active, password age, and access key age across every IAM entity
• Admin access count: aws iam list-entities-for-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess for every entity with admin attached
• Access key age: filter the credential report for keys with access_key_1_last_used_date or access_key_2_last_used_date null or >90 days

From SailPoint IdentityNow (IGA)

• Certification campaign results: the Certifications API, for completion rate, approved versus revoked decisions, and reviewer response rates
• Access request workflow: provisioning event logs, separating automated from manually provisioned grants
• SoD violations: the policy violation API, by policy and by violation age
• Role assignment coverage: role mining output, comparing users with roles to users holding direct entitlements (direct equals ungoverned)

From PAM platforms (CyberArk, BeyondTrust, Delinea)

• Vaulted credential coverage: total vaulted accounts ÷ total privileged accounts discovered
• Session recording coverage: privileged sessions with recording enabled ÷ total privileged sessions
• JIT access usage: access requests via JIT ÷ total privileged access events
• Credential age: last rotation date per vaulted credential, flagging anything not rotated in >90 days