Most identity breaches exploit weaknesses that already existed: an admin without MFA, a dormant account that still works, a service account with owner rights, an app registration with a forgotten secret, a policy exception nobody remembers. Identity security posture management (ISPM) is the practice, and increasingly the product category, of continuously finding and fixing those weaknesses across identity providers, directories, cloud platforms, SaaS and non-human identities before attackers use them. This guide explains what ISPM assesses, where posture data comes from, which baselines to measure against, how to prioritise findings and which fixes matter most. It also covers non-human identities and AI agents, running ISPM as a programme, and how it relates to IVIP and ITDR. It is written for identity architects, IAM engineers, security operations leads and the owners of identity platforms.
Key takeaways
- ISPM is posture management for identity. Like cloud security posture management, it continuously assesses configuration and hygiene and drives prioritised remediation, but its objects are accounts, roles, policies, credentials and trust relationships.
- Scope beyond the main IdP. Cover identity infrastructure (IdPs, directories, federation, sync), account hygiene (MFA, dormancy, privilege) and non-human identities (credentials, permissions, owners), including AI agents.
- Measure against a published baseline. CISA's SCuBA baseline for Microsoft Entra ID, platform secure scores and CIS Controls turn "good posture" into checkable statements.
- Prioritise by exploitability and blast radius. Privileged identities, internet-facing access without MFA and attack paths to tier zero come first.
- Posture improves only when findings close. Route each finding to an owner with a deadline, verify the fix and stop drift with guardrails.
What ISPM assesses
ISPM looks at identity as a configurable system. The checks below are typical across products and native tools; your list should reflect the platforms you run.
| Area | Example checks |
|---|---|
| Authentication | MFA coverage; phishing-resistant MFA for admins; legacy authentication enabled; weak methods such as SMS or voice; device code flow; weak recovery options |
| Privilege | Number of standing admins; Global Administrator count; privileged accounts without just-in-time activation; admin accounts synchronised from on-premises; nested group privilege |
| Account hygiene | Dormant accounts; leavers still active; shared accounts; dormant accounts in sensitive groups; non-expiring or reversible passwords |
| IdP and directory configuration | Risky tenant settings; conditional access gaps and exclusions; federation trusts; unsafe Kerberos delegation; certificate template weaknesses; clear-text credential exposure |
| Hybrid identity | Permissions and passwords of sync connector accounts; servers running sync treated as tier zero; password hash sync settings |
| Applications and OAuth | User consent settings; who can register apps; high-privilege app permissions; app passwords and their lifetimes; unowned app registrations |
| Non-human identities | Service accounts with admin rights; unused roles and access keys; unused permissions; secrets outside vaults; missing owners; reuse across environments |
| Attack paths | Chains of permissions, group memberships and delegations from ordinary accounts to tier-zero control |
| SaaS configuration | Admin counts, MFA enforcement, guest access and sharing settings in key SaaS platforms |
Many of these appear in vendors' own scoring. Microsoft's Identity Secure Score, for example, includes "Remove dormant accounts from sensitive groups", "Modify unsecure Kerberos delegations to prevent impersonation", "Rotate password for Microsoft Entra Connect AD DS Connector account" and "Stop clear text credentials exposure". See the Identity Attack Paths Guide and the Kerberos Delegation Security Guide.
Where posture data comes from
ISPM is only as good as the data behind it. Most organisations combine native tools from each platform with a cross-platform layer that joins identities across them.
| Source | What it provides | Limits to plan for |
|---|---|---|
| Microsoft Entra Identity Secure Score | A percentage showing alignment with Microsoft's recommendations, with improvement actions tailored to the tenant; available to free and paid customers | Some recommendations need a paid licence; covers Microsoft's view only |
| Microsoft Defender for Identity posture assessments | Six categories: hybrid security, identity infrastructure, certificates, group policy, accounts and cloud identities (Okta) | Needs sensors on the relevant servers; Microsoft says scores and statuses update every 24 hours |
| AWS IAM Access Analyzer | External, internal and unused access findings, including unused roles, unused IAM user access keys and passwords, and unused permissions | Unused and internal access findings are charged; per AWS organisation |
| Google Cloud IAM recommender | Role recommendations that compare granted permissions with those used in the last 90 days, plus machine learning on likely future need | Recommendations are suggestions; review before applying to service accounts |
| CISA ScubaGear | Automated checks of Microsoft 365 tenants against the SCuBA baselines | Microsoft 365 only; some policies need manual verification |
| Cross-platform ISPM or IVIP products | A joined view of human and non-human identities, privileges and attack paths across IdPs, directories, clouds and SaaS | Connector coverage and data freshness vary; validate against native tools |
Pick one system of record for findings so that a misconfiguration reported by two tools becomes one ticket, not two. See the IVIP Guide and the Cloud PAM and CIEM Guide.
Baselines to measure against
A finding is easier to act on when it cites a published expectation. CISA's Secure Cloud Business Applications (SCuBA) baseline for Microsoft Entra ID is mandatory for US federal civilian agencies and, CISA says, may be useful to other organisations as a reference. Each policy is a short, testable statement:
| SCuBA policy | Statement | Posture check it supports |
|---|---|---|
| MS.AAD.1.1v1 | Legacy authentication SHALL be blocked | No sign-in path bypasses MFA |
| MS.AAD.3.1v1 / 3.6v1 | Phishing-resistant MFA SHALL be enforced for all users / required for highly privileged roles | MFA strength by role |
| MS.AAD.3.9v1 | Device code authentication SHOULD be blocked | Risky authentication flows |
| MS.AAD.5.1v1 / 5.2v1 | Only administrators SHALL be allowed to register applications / user consent SHALL be restricted | OAuth app sprawl and consent phishing |
| MS.AAD.5.6v1 | Application password lifetime SHOULD be restricted to 180 days or less | Long-lived app secrets |
| MS.AAD.7.1v1 | A minimum of two users and a maximum of eight users SHALL be provisioned with the Global Administrator role | Standing admin count |
| MS.AAD.7.3v1 / 7.4v1 | Privileged users SHALL be provisioned cloud-only accounts / permanent active assignments SHALL NOT be allowed for highly privileged roles | Hybrid admin exposure, just-in-time coverage |
| MS.AAD.9.1v1 | Risky AI agents SHALL be blocked | Agent identity posture |
CISA's rationale for MS.AAD.7.1v1 notes that Microsoft recommends fewer than five Global Administrators, with up to eight allowed for emergency access and operational needs. For other platforms, use the vendor's hardening guidance and CIS benchmarks. See the Microsoft 365 Security Guide and the Okta Security Hardening Guide.
Prioritising findings
ISPM tools can produce thousands of findings, and a flat list sorted by tool severity rarely matches real risk. Score each finding on a few factors and work from the top:
| Factor | Ask | Raises priority when |
|---|---|---|
| Privilege | What can this identity do? | It holds a tier-zero or highly privileged role, or can grant one |
| Exposure | Who can reach it? | It is internet-reachable, externally federated or connected to a third party |
| Exploitability | Is there a known, active technique? | MFA gaps, password-only remote access, Kerberoastable service accounts, consent phishing exposure |
| Attack path | Is it a step on a route to high-value assets? | Fixing it breaks one or more paths to tier zero |
| Data and business impact | What would compromise expose? | It reaches regulated data, production or payment systems |
| Ownership | Does anyone answer for it? | No owner, or the owner has left |
MITRE ATT&CK helps with exploitability. Valid Accounts (T1078) notes that adversaries may abuse inactive accounts, such as those of people who have left, because the original user will not notice. Kerberoasting (T1558.003) shows why a service account with a weak password and a service principal name is a high-priority finding: any user with a valid ticket can request a service ticket and crack it offline.
Common high-value fixes
The same handful of fixes appear in baselines, secure scores and incident reports. They are worth doing before tuning any scoring model.
- Phishing-resistant MFA for administrators, then for everyone (SCuBA MS.AAD.3.6v1 and 3.1v1). See the Passwordless and Passkeys Guide.
- Block legacy authentication and other flows that bypass MFA. See the Conditional Access Guide.
- Cut standing privilege: reduce Global Administrators and Domain Admins, use finer-grained roles and require just-in-time activation with approval for the most powerful roles. See the JIT Access Guide.
- Separate cloud admin accounts from on-premises synchronised accounts, so a domain compromise does not become a tenant compromise.
- Disable dormant and leaver accounts, starting with those in sensitive groups and those with remote access.
- Remove service accounts from privileged groups, rotate old credentials and give each an owner. See the Service Account Security Guide.
- Restrict app registration and user consent, configure an admin consent workflow and remove high-risk unused apps. See the Entra ID Applications and Consent Guide.
- Close conditional access exclusions that are no longer needed, and review every remaining one on a schedule.
Non-human identities and AI agents
Non-human identities usually outnumber people and are where posture tools find the oldest credentials and the broadest permissions. The OWASP Non-Human Identities Top 10 (2025) reads as a posture checklist: Improper Offboarding (NHI1), Secret Leakage (NHI2), Overprivileged NHI (NHI5), Long-Lived Secrets (NHI7), Environment Isolation (NHI8), NHI Reuse (NHI9) and Human Use of NHI (NHI10).
- Inventory and owners: every service account, service principal, workload identity, API key and certificate needs an owner, a purpose and a review date. See the Service Account Inventory Template.
- Unused access: AWS IAM Access Analyzer and Google's IAM recommender both report unused roles, keys or permissions; feed them into the same remediation queue as human findings.
- Hybrid sync accounts are tier zero: in the Storm-0501 Hybrid Cloud Attacks 2024, Microsoft says the group extracted Entra Connect Sync credentials and used a Domain Admin whose cloud account had MFA disabled and held Global Administrator.
- Legacy apps keep their rights: in the Microsoft Midnight Blizzard Breach 2024, a password spray on a legacy test tenant account led to a legacy test OAuth application with elevated access to the corporate environment.
- AI agents: agents act autonomously with delegated or their own credentials, so assess their identities like any other NHI: owner, scope, credential type and lifetime, and whether risk-based blocking applies. CISA added MS.AAD.9.1v1, "Risky AI agents SHALL be blocked", noting agents "can perform actions autonomously". See the Identity Governance for AI Agents Guide and the Shadow AI Discovery Guide.
Running ISPM as a programme
- Scope and baseline: list every identity system in scope, including SaaS and NHI sources, assess them and publish a starting set of metrics. Choose the baselines you measure against.
- Assign: route findings to the owners of each system and identity, with severity-based deadlines agreed in advance. A finding without an owner is itself a finding.
- Remediate: fix high-severity items first; automate safe, repeatable fixes such as disabling long-dormant accounts after notice.
- Verify: re-run the check after each fix; close the ticket only on evidence, not on the owner's word.
- Prevent drift: detect new misconfigurations as they occur, and add guardrails in policy, infrastructure as code and identity provisioning so the same issue cannot return.
- Manage exceptions: record accepted risks with an approver and an expiry date; review them like access.
- Report: track trends for leadership and platform owners. See the Identity Security Metrics Guide.
Small teams can start with native secure scores and ScubaGear on a monthly cycle. Larger organisations usually need a cross-platform tool, a ticketing integration and an identity platform owner who chairs a regular posture review.
ISPM, IVIP and ITDR
| Capability | Question it answers | Typical output |
|---|---|---|
| ISPM | Where are we weak before anyone attacks? | Misconfigurations, hygiene gaps, attack paths, remediation tickets |
| ITDR | Is someone exploiting identity now? | Detections, alerts, response actions such as session revocation |
| IVIP | Who and what exists, and what can each identity reach? | A unified identity graph across sources that ISPM and ITDR both use |
Many products combine two or three of these. What matters is that posture findings, detections and identity context feed each other: an ITDR alert on an account with open posture findings should be escalated, and every confirmed incident should produce a posture check that would have caught it. See the ITDR Guide and the IVIP and ISPM Buyer's Guide.
Framework mapping
This is an indicative alignment prepared by NHI Mgmt Group, not an official mapping. Control IDs were checked against the NIST CSF 2.0 text, the NIST SP 800-53 Rev. 5 catalogue, a published ISO/IEC 27001:2022 Annex A list and the OWASP NHI Top 10 (2025); CIS Controls v8.1 are given at control level.
| ISPM activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP NHI Top 10 |
|---|---|---|---|---|---|
| Identity inventory and ownership | PR.AA-01, ID.AM-02 | AC-2, IA-4 | A.5.16 | 5 | NHI1 |
| Configuration baselines and drift | PR.PS-01 | CM-2, CM-6 | A.8.9 | 4 | |
| MFA and authentication strength | PR.AA-03 | IA-2(1), IA-2(2) | A.8.5 | 6 | NHI4 |
| Privilege review and reduction | PR.AA-05 | AC-6, AC-6(7) | A.5.18, A.8.2 | 6 | NHI5 |
| Dormant and leaver accounts | PR.AA-01 | AC-2(3) | A.5.18 | 5 | NHI1 |
| Credential age and leakage | PR.AA-01 | IA-5 | A.5.17 | 5 | NHI2, NHI7 |
| Finding, scoring and tracking weaknesses | ID.RA-01, ID.RA-06 | RA-5 | A.8.8 | 7 | |
| Continuous monitoring and reporting | DE.CM-03, GV.OV-03 | CA-7 | A.8.16 | 8 |
Common failure patterns
- One exception becomes the entry point: UnitedHealth's chief executive told Congress the Citrix portal used for initial access in the Change Healthcare Breach 2024 "did not have multifactor authentication".
- Dormant accounts left enabled: Mandiant said the VPN account behind the Colonial Pipeline Ransomware Attack 2021 was no longer used but had not been disabled, and its password appeared in a leaked batch.
- Non-production treated as out of scope: the Midnight Blizzard entry point was a legacy test tenant account without MFA.
- Single-factor access to data platforms: Mandiant tied the Snowflake Breach 2024 to accounts without MFA, credentials not rotated for years and no network allow lists.
- Score chasing: teams fix the cheapest recommendations to raise a percentage while tier-zero findings stay open.
- Findings without owners: reports go to a central team that cannot change the systems, so nothing closes.
- Humans only: service accounts, app registrations and agents are excluded, leaving the oldest credentials unassessed.
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Open critical and high findings on privileged identities | Tier-zero exposure | Down |
| Median age of open high findings | Remediation speed | Down |
| Accounts with phishing-resistant MFA, admins and all users | Authentication strength | Up, to 100% for admins |
| Standing highly privileged role assignments | Zero standing privilege progress | Down |
| Dormant accounts still enabled | Hygiene | Down |
| NHIs with a named, current owner | Accountability | Up |
| Unused roles, keys and permissions | Excess access | Down |
| Attack paths to tier zero | Blast radius | Down |
| Findings reopened after closure | Drift and fix quality | Down |
Implementation roadmap
| Phase | Actions | Outcome |
|---|---|---|
| First 30 days | Agree scope; run native secure scores, ScubaGear and cloud access analysis tools; fix MFA gaps on admins and remote access; block legacy authentication; disable obviously dormant privileged accounts | A baseline and the most exploitable gaps closed |
| Days 31 to 90 | Name owners for systems and NHIs; set severity deadlines; integrate findings with ticketing; move highly privileged roles to just-in-time; restrict app consent; start exception register | A working remediation loop with accountability |
| Days 91 to 180 | Add cross-platform attack path analysis; extend to SaaS and AI agents; add drift guardrails in infrastructure as code; link ISPM to ITDR escalation; report trends quarterly | Continuous posture management across human and non-human identities |
Practitioner checklist
- Define the identity systems in scope, including directories, IdPs, clouds, SaaS, NHI sources and AI agents.
- Choose published baselines, such as SCuBA for Microsoft Entra ID and CIS benchmarks, and record deviations.
- Run a baseline assessment with native tools and agree a small set of metrics.
- Prioritise by privilege, exposure, exploitability, attack paths and ownership.
- Enforce phishing-resistant MFA for admins and block legacy authentication first.
- Route findings to named owners with deadlines, and verify every fix by re-running the check.
- Assess service accounts, app registrations and agents with the same rigour as people.
- Monitor continuously for configuration drift and add guardrails to stop repeats.
- Keep an exception register with approvers and expiry dates.
- Connect posture findings with ITDR and access governance processes.
Standards and references
- CISA: SCuBA M365 Secure Configuration Baseline for Microsoft Entra ID
- NIST: Cybersecurity Framework (CSF) 2.0
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- CIS: Critical Security Controls Version 8.1
- OWASP: Non-Human Identities Top 10 (2025)
- MITRE ATT&CK: TA0004 Privilege Escalation
- MITRE ATT&CK: T1078 Valid Accounts
- MITRE ATT&CK: T1558.003 Kerberoasting
- Microsoft: What is the Identity Secure Score?
- Microsoft: Defender for Identity security posture assessments
- AWS: IAM Access Analyzer findings
- Google Cloud: Overview of role recommendations
Related NHI Mgmt Group resources: IVIP and ISPM Buyer's Guide · Active Directory and Entra ID Hardening Guide · Identity Provider and SSO Security Guide · ITDR Guide · NHI Lifecycle Management Guide