Part 2 of 3

By Vidyaa Ganesh

This is Part 2 of a three-part series on IAM maturity measurement. Part 1 reviewed the published research showing that 60-70% of organizations remain at early-to-mid stages of IAM maturity. This installment examines the frameworks currently available and the structural reasons no standard has emerged.

If 60% to 70% of organizations are stuck at early-to-mid stages of IAM maturity, as five independent research sources consistently show, a natural question follows: why can’t they measure and track their way out? The answer is not that frameworks are absent. Several exist. The answer is that they are incompatible with each other and, in most cases, not designed for cross-organizational comparison.

CMMI and General-Purpose Maturity Models

The Capability Maturity Model Integration, now maintained by ISACA, provides a well-established framework for assessing process maturity across domains. Its five-level structure (Initial, Managed, Defined, Quantitatively Managed, Optimizing) has been widely adopted outside its original software engineering context. CMMI’s staged representation introduces an important concept: lower-level capabilities must be satisfied before higher levels can be claimed. An organization cannot skip foundational process areas and still achieve a high maturity rating.

CMMI’s limitation for IAM is that it is domain-agnostic. It provides structure and principles, but it does not define what IAM-specific capabilities should be measured, how they should be weighted, or what constitutes a reasonable benchmark for a given industry.

Gartner IAM Program Maturity Model

Gartner’s IAM Program Maturity Model, published in September 2025, defines six dimensions of IAM maturity across five levels. It is perhaps the most authoritative vendor-neutral reference available, and its dimension structure (covering governance, identity lifecycle, access management, privileged access, and related areas) reflects a comprehensive view of what IAM programs should include.

However, the model is paywalled, which limits its utility as a shared community standard. It also does not publish empirical benchmark data showing where organizations in specific industries typically fall on its scale. Without that benchmark layer, an organization can assess itself against the model’s definitions but has no way to know how it compares to its peers.

SailPoint Horizons Framework

SailPoint’s Horizons framework is notable because it publishes actual empirical data. The five-horizon model is based on annual surveys, uses a clustering algorithm to assign organizations to maturity levels, and breaks results out by industry, geography, and organizational size. It also explicitly incorporates the concept of capability prerequisites: to be placed in a given horizon, an organization’s capabilities must cover most environments and identity types.

The limitation is that SailPoint is a vendor with commercial interests in the identity governance space. While the research methodology appears sound, a vendor-published framework will always face questions about objectivity, particularly when the recommended path to higher maturity runs through capabilities that the vendor sells.

CISA Zero Trust Maturity Model

The Cybersecurity and Infrastructure Security Agency published a Zero Trust Maturity Model that includes an identity pillar with explicit maturity levels. It is publicly available and government-backed, which gives it credibility. The model explicitly states dependencies between pillars: identity capabilities must be established before device trust or network trust can be meaningful.

The model is scoped to zero trust architecture, not IAM broadly. It does not cover domains like identity governance and administration, customer identity, or the operational and organizational dimensions of an IAM program. It is useful as a reference but incomplete as a general-purpose IAM maturity standard.

Vendor-Specific Models

Several vendors have published maturity models specific to their market segment. Okta published a four-stage CIAM maturity curve (Basic, Automated, Intelligent, Continuous). Auth0, now part of Okta, published an Identity Maturity Framework with six assessment dimensions. WSO2 published a five-level CIAM maturity model.

These models are useful for understanding capability progression within a specific domain, but they share a common limitation: none publishes empirical data about where organizations actually fall on their respective scales. They define the levels but do not populate them with benchmark data.

The Comparability Problem

The fundamental issue is not that frameworks are absent. It is that they are mutually incompatible. An organization assessed using SailPoint’s five-horizon model cannot compare its results to one assessed using Bravura’s four-level model or Gartner’s six-dimension framework. The scales differ, the dimensions differ, the weighting logic (where it exists) differs, and the definitions of what constitutes each level differ.

For IAM practitioners, this means that changing consultants often means starting the measurement process from scratch. For CISOs reporting to boards, it means that year-over-year comparisons are only valid if the same assessment approach is used each time. For the industry as a whole, it means there is no aggregate data pool that could raise the bar for everyone.

Table 2. Comparison of existing IAM maturity frameworks

Why No Standard Has Emerged

Given the clear need for standardized measurement, it is reasonable to ask why one does not already exist. Several structural factors have worked against the emergence of a shared standard.

Vendor incentives cut against standardization. Identity vendors benefit from publishing their own maturity models because it frames the conversation in terms of their product capabilities. A vendor’s maturity model will, almost by definition, position the vendor’s strongest features as markers of advanced maturity. This creates a structural incentive against converging on a shared, vendor-neutral standard.

IAM spans too many domains. IAM encompasses identity governance and administration, privileged access management, workforce authentication, customer identity, cloud identity, identity threat detection, and governance and strategy. Each has its own maturity curve, vendor landscape, and regulatory drivers. Building a single model that meaningfully covers all of them requires significant domain expertise and difficult weighting decisions.

No governing body has taken ownership. Unlike financial accounting (which has GAAP and IFRS) or software process maturity (which has CMMI), identity management does not have a single governing body that has taken responsibility for defining and maintaining a measurement standard. Organizations like IDPro, IDSA, NIST, and ISACA each contribute pieces of the puzzle, but none has published a comprehensive, empirically-grounded IAM maturity standard.

Measurement requires difficult methodological choices. How should domains be weighted against each other? Should privileged access management carry more weight than governance? How do you handle the scenario where an organization scores highly in advanced areas but has gaps in foundational controls? These are not trivial questions, and without empirical data to validate different approaches, any methodology choice can be challenged.

The CIAM measurement gap. While workforce IAM has at least some benchmark data available, the CIAM space has essentially none. Gartner’s 2025 research found that over 50% of organizations still use homegrown or no CIAM solution at all. Multiple vendors have published CIAM maturity models, but none has published empirical data about where organizations actually fall on those models.

Endnotes

9. ISACA, CMMI Version 3.0 (CMMI Institute/ISACA, 2023).

10. Gartner, Inc., Identity and Access Management Program Maturity Model (September 2025), Document ID: 1203314.

11. SailPoint, Horizons 2025-2026, Appendix, p. 44.

12. Cybersecurity and Infrastructure Security Agency, Zero Trust Maturity Model (CISA, 2023).

13. Okta, Inc., From Zero to Hero: The Path to CIAM Maturity (Okta eBook).

14. Auth0/Okta, Auth0 Identity Maturity Framework (IMF) (Auth0, 2021).

15. WSO2, A Maturity Model for Customer IAM (WSO2 Blog).

16. Gartner, Inc., Innovation Insight for Customer and Partner IAM (April 2025).

NEXT IN THIS SERIES

Part 3: What Good Measurement Looks Like

If the IAM community is going to move toward standardized measurement, what would a credible framework need to include? Seven design principles, the open questions that remain, and a call to action.

About the Author

Vidyaa Ganesh is a Senior IAM Engineer and a solutions architect with over six years of experience delivering identity governance programs for financial services, energy, telecommunications, and public sector clients. She holds a Master of Engineering from Concordia University, is a member of IDPro, and is the creator of AXIS (axis.identara.ca), an open IAM maturity assessment framework.

The post A Landscape of Incompatible Approaches appeared first on IDPro.

Part 1 of 3

By Vidyaa Ganesh

Five independent sources, 2,000+ respondents, one conclusion: most organizations cannot measure their IAM maturity. And that is a problem.

Identity and access management has become one of the most consequential areas of enterprise security. The IDSA’s 2024 survey of 521 security professionals found that 90% of organizations experienced at least one identity-related security incident in the prior 12 months, with 84% reporting direct business impact. IBM’s 2025 Cost of a Data Breach report, based on 600 organizations and over 3,400 interviews, puts the global average breach cost at $4.88 million, with compromised credentials remaining the most common initial attack vector.

These numbers create obvious pressure for organizations to invest in IAM. And they are investing. But a harder question follows: how do you know whether your IAM program is actually working? How do you measure where you stand relative to your industry, track improvement over time, or communicate your posture to a board of directors in terms that hold up to scrutiny?

The honest answer, as of early 2026, is that most organizations cannot do any of these things reliably. There is no widely accepted, vendor-neutral framework for measuring IAM maturity. What exists instead is a patchwork of vendor-specific models, consultant-developed scorecards, and ad hoc approaches that vary from one engagement to the next. The measurements produced by these approaches cannot be compared across organizations, across time, or even across different consultants assessing the same organization.

This is the first installment in a three-part series examining this problem. In this piece, we look at what the published research actually says about where organizations stand. In Part 2, we survey the frameworks currently in use and analyze why no standard has emerged. In Part 3, we propose design principles that a credible, community-adopted standard would need to follow.

What Published Research Tells Us

Before discussing what a standard should look like, it is worth understanding what the data actually says about where organizations stand. Several independent research efforts have attempted to measure IAM maturity across large populations, and their findings tell a remarkably consistent story.

SailPoint Horizons of Identity Security (2025-2026)

SailPoint’s annual Horizons research surveyed 375 IAM decision-makers across North America, Europe, Asia, and Latin America. The study evaluates organizations across four enablement areas (strategy, technology and tools, operating model, and talent) covering 60 IAM capabilities, then assigns each organization to one of five maturity horizons using a clustering algorithm.

The headline finding is striking: over 40% of organizations remain at Horizon 1, the lowest maturity level. These are organizations where identity is not a strategic focus, capabilities are highly immature, and there is no centralized operating model for managing identities across the organization. When you include Horizon 2, the number climbs to roughly 63% of organizations stuck at the bottom two tiers.

Industry breakdowns reveal meaningful variation. In financial services, 34% are at Horizon 1, with 13% reaching Horizon 4 or above. In technology, the distribution is bimodal: 46% at Horizon 1, but 15% at Horizon 4 or higher, reflecting a split between early-stage companies with minimal IAM investment and mature enterprises with sophisticated programs.

Ponemon Institute and GuidePoint Security (2025)

The Ponemon Institute, in partnership with GuidePoint Security, surveyed 626 IT professionals on the state of IAM maturity in 2025. On a 10-point effectiveness scale, only 50% of respondents rated their IAM tools as effective (scoring 7 or higher). Just 23% qualified as high performers, rating their effectiveness at 9 or 10.

The study also found that 50% of organizations experienced an identity-related incident in the prior 12 months. Even among high performers, 39% still experienced incidents, compared to 58% for others. Manual processes remain dominant: 34% of organizations still use spreadsheets for access reviews, and only 17% use an identity governance platform for this purpose.

IDSA Trends in Identity Security (2024)

The Identity Defined Security Alliance surveyed 521 qualified security professionals at organizations with 1,000 or more employees. The findings reinforce the pattern: 90% experienced an identity-related incident, 84% reported direct business impact, and 91% invoked their incident response plans for identity-related events.

When asked to self-assess their maturity, only 8% of respondents placed their organization at the highest level. The majority clustered in the middle tiers, suggesting widespread acknowledgment that current capabilities are insufficient.

Other Sources

Bravura Security, in partnership with Gartner Peer Insights, conducted a smaller study of 100 IT leaders across North America and EMEA using a four-level maturity scale. Their finding: the average organization falls between levels 2 and 3 on a four-point scale, consistent with the other sources.

Simeio’s State of Identity research, covering 80 measures across industries, found a cross-industry average maturity of 2.4 on a five-point scale. Financial services scored highest at approximately 2.6, with healthcare and public sector trailing.

What the Data Tells Us

Five independent research efforts, using different scales, different sample sizes, and different methodologies, converge on the same conclusion: the majority of organizations, somewhere between 60% and 70%, remain at early-to-mid stages of IAM maturity. The consistency across sources is significant. This is not one vendor telling a convenient story. It is a pattern that holds up regardless of who is asking the question or how they frame it.

Table 1. Cross-source validation of IAM maturity findings

NEXT IN THIS SERIES

Part 2: A Landscape of Incompatible Approaches

Several maturity frameworks exist in the IAM space. Each offers something useful. None has achieved the status of a shared standard. We examine why.

Endnotes

1. Identity Defined Security Alliance, 2024 Trends in Securing Digital Identities (IDSA, 2024), 521 respondents.

2. IBM Security, Cost of a Data Breach Report 2025 (Ponemon Institute Research, 2025), 600 organizations, 3,470 interviews.

3. SailPoint Technologies, The Horizons of Identity Security 2025-2026 (SailPoint, July 2025), 375 IAM decision-makers.

4. SailPoint, Horizons 2025-2026, Exhibit 7, p. 15.

5. Ponemon Institute and GuidePoint Security, The State of Identity and Access Management (IAM) Maturity (May 2025), 626 IT professionals.

6. Identity Defined Security Alliance, 2024 Trends in Securing Digital Identities (IDSA, 2024).

7. Bravura Security and Gartner Peer Insights, IAM & PAM Maturity Survey (Bravura Security, 2024), 100 IT leaders.

8. Simeio, State of Identity 2024 (Simeio Solutions, 2024).

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

About the Author

Vidyaa Ganesh is a Senior IAM Engineer and a solutions architect with over six years of experience delivering identity governance programs for financial services, energy, telecommunications, and public sector clients. She holds a Master of Engineering from Concordia University, is a member of IDPro, and is the creator of AXIS (axis.identara.ca), an open IAM maturity assessment framework.

The post The Measurement Problem appeared first on IDPro.

Role: Cybersecurity Executive | “Identity-First” Security Leader

What IAM practitioners need to understand about the human cost hiding inside your compliance checklist…

The Pattern Nobody Talks About Out Loud

Every major regulatory framework you work against was written in response to something that already went wrong. Not hypothetically wrong. Catastrophically, publicly, irreversibly wrong. We don’t build policy proactively in this industry; we build it reactively, after the damage has been done and the headlines have forced someone’s hand.

Think about what’s sitting underneath the frameworks you navigate daily.

• HIPAA didn’t emerge from healthcare executives deciding patient data deserved protection. It emerged from a landscape of rampant insurance fraud, discriminatory data practices, and medical record abuses that left real people with real consequences – lost jobs, denied coverage, destroyed privacy. The law was the cleanup crew, not the prevention.
• SOX didn’t come from auditors deciding financial controls needed tightening. It came after Enron and WorldCom vaporized billions in investor value and shredded retirement accounts for thousands of ordinary people who trusted the numbers they were shown. The Act is a forensic document masquerading as a compliance framework.
• GDPR wasn’t a vision for a privacy-respecting digital future. It was a regulatory response to years of data harvesting, unconsented profiling, and cross-border data abuses that regulators finally couldn’t ignore after Facebook’s Cambridge Analytica exposure became impossible to contain politically.
• The Amber Alert system is named after Amber Hagerman, a nine-year-old murdered in Arlington, Texas in 1996. The system that now protects children didn’t exist until a child was killed and her community demanded something change.
• PCI-DSS exists because card fraud became so pervasive and so costly to the financial ecosystem that the major card networks had no choice but to mandate baseline controls across every merchant touching card data. The standard didn’t anticipate the breach, it was written after thousands of them.

This is the pattern. Harm occurs. Harm scales. Harm becomes undeniable. Regulation follows. And then we all inherit the compliance framework and treat it like it arrived from nowhere, like it was always just the way things were.

It didn’t arrive from nowhere. It arrived from graves.

IAM Is No Different – Here Are the Breaches That Wrote Your Policies

The identity space follows the same pattern exactly. The controls we build and enforce today weren’t invented in a vacuum by forward-thinking architects. They were demanded by specific, named failures that exposed how badly we were underinvesting in identity fundamentals.

• Target (2013): The breach wasn’t a sophisticated nation-state attack. An HVAC vendor with network access and no meaningful segmentation became the entry point for 40 million stolen card records. The core failure was third-party identity governance, an external account with far more privilege than its function required, and no monitoring to detect its abuse. Every time I review a vendor access policy, this breach is in the room.
• SolarWinds (2020): Supply chain compromise at massive scale, enabled in part by service accounts operating with excessive privilege across thousands of customer environments. The attackers didn’t force their way in, they walked through doors that were left open by over-permissioned build pipeline identities and inadequate separation between production and development access.
• Colonial Pipeline (2021): A single compromised VPN account with no MFA enforced. One identity. No second factor. Fuel supply disruption across the eastern United States. Every MFA mandate that landed in your organization after 2021 has this incident’s fingerprints on it.
• Uber (2022): A contractor’s credentials obtained through MFA fatigue, repeated push notifications until the user accepted to stop the noise. The attacker then moved laterally through internal systems because access controls weren’t scoped tightly enough to limit blast radius. The failure wasn’t technical sophistication. It was operational immaturity in how MFA was implemented and how privilege was bounded.
• Microsoft (2023): A stolen MSA signing key used to forge authentication tokens across cloud tenants. The identity trust model itself became the attack surface. When cryptographic key management fails, every downstream access decision built on top of it is compromised.
• MGM Resorts (2023): Attackers identified a senior employee via LinkedIn, called the IT help desk impersonating them, and convinced the agent to reset credentials and MFA with no callback protocol, no strong out-of-band verification. Caesars Entertainment was hit the same month by the same pattern. The failure wasn’t in the authentication stack. It was in the help desk itself. The layer where humans prove humans and deepfake voice and video now make that layer trivial to defeat at scale.

Each of these is an IAM failure. Excessive privilege. Missing MFA. Orphaned accounts. Poor federation hygiene. Inadequate key lifecycle management. Help desk identity verification. The controls that now appear in your compliance frameworks have these incident names written invisibly inside them.

What Compliance Actually Tells You (And What It Doesn’t)

Here’s the uncomfortable truth about compliance frameworks: they are lag indicators by design. They codify the minimum bar required to prevent the breach that already happened. They say nothing reliable about the breach that’s being planned right now.

The gap between a compliance checkbox and mature IAM posture is where the next incident is living. I see this gap constantly, and it’s worth naming directly.

• MFA enabled versus phishing-resistant MFA enforced at the authentication policy layer hardware-bound, not just a push notification toggle sitting in a dashboard that nobody monitors for fatigue patterns.
• Privileged access documented versus PAM operationally enforced with just-in-time provisioning, session recording with active review, and standing access treated as a policy exception rather than the default.
• Access reviews completed versus access reviews that actually reduce privilege, where the outcome of the review cycle is measurably fewer entitlements per identity, not just a signed-off spreadsheet that nobody acted on.
• Service accounts inventoried versus non-human identities continuously monitored with behavioral baselines, anomaly alerting, and rotation schedules enforced by automation rather than calendar reminders.
• Zero Trust policy adopted versus a network architecture where identity is actually the control plane, not a slide in a board presentation, and where access decisions factor not just who the user is, but where they are, what device they’re on, and whether their current behavior looks like their baseline.

Identity used to answer “are you allowed?” It now has to answer “does this access attempt even look like you?” Impossible travel, high-risk geographies, session risk, device posture — these belong inside the authentication decision, not inside a dashboard someone reviews on Mondays.

• IAM capabilities deployed versus IAM KPIs tracked and trended over time because what doesn’t get measured doesn’t improve, and the maturity of an identity program shows up in the shape of its metric curves, not in the inventory of tools on the license schedule. If you can’t tell me whether entitlements-per-identity is declining, whether standing privilege has shrunk quarter over quarter, or how long a new joiner waits for correct access – you don’t have a program posture, you have a tool stack.

Compliance tells you what the floor looks like. It does not tell you where the ceiling is. And in my experience, most organizations have stopped somewhere between the two and called it done.

The Dangerous Comfort Zone: When Your Team Mistakes Compliance for Security

The organizational behavior this creates is one of the most persistent problems I work against. When audit cycles become the primary driver of the IAM roadmap, the team’s incentive structure warps in a specific and dangerous direction.

You stop optimizing for threat reduction. You start optimizing for evidence collection.

I’ve seen this show up in recognizable patterns across organizations of every size.

• Quarterly access reviews conducted as rubber stamps, certifiers clicking approve on hundreds of entitlements in minutes because the process was designed to generate a record, not to generate a decision. The question being answered isn’t “does this person need this access?” It’s “how quickly can we close the certification campaign?”
• Role proliferation allowed to compound year over year because the current roles passed the last audit, so nobody wants to touch them. The organization is carrying thousands of roles, most of which are poorly defined, overlapping, and impossible to audit meaningfully but the audit passed, so the conversation doesn’t happen.
• PAM tools deployed, licensed, and documented and operationally ignored. The vault exists. The accounts are technically onboarded. But privileged sessions aren’t being reviewed, standing access is still the default, and the tool that was supposed to transform privileged access management is functioning as an expensive credential repository.
• IGA platforms configured to enforce policy at provisioning and then left unmonitored for drift. Accounts created with the right access on day one, accumulating entitlements through ad-hoc requests for three years, and nobody has looked at the aggregate picture because the provisioning workflow is compliant.

If any of this feels familiar, I’m not judging the team rather I’m naming the system. When compliance is the primary success metric, this is the rational response to the incentive structure. The problem is that rational compliance behavior and effective security behavior are not the same thing, and the gap between them is where attackers operate.

IAM practioners shoould put it plainly to leadership: Audit Ready is not the same as Breach Proof. A team optimizing for closing the certification campaign rather than reducing the risk the entitlement actually carries will produce a clean audit and a vulnerable organization at the same time. The moment those two phrases get conflated above the CISO’s head, the program inherits a mandate that looks like security but isn’t.

How to Get Ahead of the Grave – A Practitioner’s Operating Model

Diagnosis without direction isn’t useful. So here is the operating model I apply when I want to move an identity program from reactive compliance posture to proactive threat-informed design. This isn’t theoretical, it’s what actually works in practice.

The list is structured deliberately: the first six harden your posture against breach patterns already on public record; the seventh forces your program to keep pace with threats no auditor has yet catalogued.

1. Threat-model your identity fabric before you scope your controls. Start with adversary behavior, not framework requirements. Map the specific identity attack paths relevant to your environment — credential theft, privilege escalation, lateral movement via federated trust, non-human identity abuse. Then ask which of your current controls actually interrupt those paths and which ones only satisfy an auditor.

• A frame worth internalizing here, from John Lambert: defenders think in lists, attackers think in graphs, and as long as that’s true, attackers win. Your access review spreadsheet is a list. The web of trust between your identities, groups, federations, service accounts, and privileged resources is a graph, and that graph is the terrain your adversary is actually traversing.

2. Define your identity tiers and map blast radius per tier explicitly. Not all identities carry equal risk. A tier-one privileged identity with access to production infrastructure and administrative federation capabilities has an entirely different blast radius than a standard user account. Your controls, monitoring intensity, and response playbooks should reflect that difference. If they don’t, you’re applying uniform protection to non-uniform risk.
3. Run tabletop exercises scoped specifically to identity failure modes. Most tabletops I’ve participated in simulate perimeter or endpoint compromises. Run the scenario where your IdP is compromised. Run the scenario where a service account with excessive privilege is abused by an insider. Run the scenario where MFA is defeated at scale through fatigue or SIM swapping. The gaps that surface in those conversations are the gaps that matter.
4. Red team your identity layer – don’t wait for a real incident to find the gaps. Tabletops surface the failures you can imagine; adversarial testing surfaces the ones you can’t. Commission identity-focused red team engagements on a recurring cadence — credential theft, session hijack, federation abuse, privilege escalation, help desk social engineering and feed what they find back into architecture rather than filing it as a report. Gaps that never appear in access reviews or audits almost always appear under someone actually trying to break in.
5. Instrument your IGA for behavioral anomaly, not just policy violation. Policy enforcement catches known-bad. Behavioral analytics surface unknown-bad. If your identity governance platform is only alerting when a provisioning rule is violated, you’re blind to the user whose access pattern changed three months ago in ways that no individual action violated policy but the aggregate behavior is deeply suspicious.
6. Build your access review process around privilege reduction as the measurable outcome. Track entitlements per identity over time. Make the success metric a declining curve, not a closed certification campaign. If your access reviews aren’t resulting in access removal, they aren’t reviews, they’re rituals.
7. Treat non-human identity with the same rigor as privileged human identity. Service accounts, API keys, OAuth tokens, pipeline credentials – these are the identities attackers are targeting at scale right now because they’re often under-governed and over-privileged. If you don’t have a comprehensive non-human identity inventory with ownership, purpose, and lifecycle enforcement, this is the highest-priority gap in most environments I’ve seen.
8. Plan for the attacks your compliance framework hasn’t named yet. The controls in your baseline were written against breaches that have already happened. Deepfake-assisted help desk impersonation, AI-generated vishing, synthetic identity fraud, ML-enhanced MFA fatigue — these are landing in production right now and appear in no auditor’s checklist. Build a forward-looking layer into your program that tracks emerging identity threats quarterly, runs tabletop exercises against them, and lands the control before the framework tells you to.
9. Rehearse the recovery, not just the detection. Assume the breach has already landed. Do the right people know their roles, and are they reachable at 3 a.m. on a holiday? How fast can you rotate privileged credentials at scale, sever federated trust, and re-establish a known-good authentication plane? Most programs have never actually measured how long identity recovery would take under real conditions. Find out before an attacker makes you find out.
10. Plan for the attacks your compliance framework hasn’t named yet. The controls in your baseline were written against breaches that have already happened. Deepfake-assisted help desk impersonation, AI-generated vishing, synthetic identity fraud, ML-enhanced MFA fatigue – these are landing in production right now and appear in no auditor’s checklist. Build a forward-looking layer into your program that tracks emerging identity threats quarterly, runs tabletop exercises against them, and lands the control before the framework tells you to.

The Obligation We Carry as IAM Practitioners

I want to end with something direct, because I think it matters.

The people building identity infrastructure today are either providing the incident report that writes the next regulation, meeting the one that already exists, or for the few doing this exceptionally well, quietly setting the bar that tomorrow’s framework will codify as the new minimum, not because something went wrong but because it got done right first.

There is no neutral position. The access controls you enforce or fail to enforce, the privilege you scope or over-grant, the MFA you deploy meaningfully or deploy performatively, all of it is making a real-world determination about whether the next catastrophic breach happens on your watch and in your environment.

That’s not meant to be dramatic. It’s meant to be accurate.

Reframing what good IAM work actually means is worth doing explicitly.

• Good IAM work is not completing a certification campaign on time. It is ensuring that the humans approving entitlements are actually examining them and removing the ones that shouldn’t exist.
• Good IAM work is not deploying a PAM tool. It is operationalizing privileged access controls to the point where standing access is genuinely exceptional and every privileged session is visible and accountable.
• Good IAM work is not enforcing MFA across the enterprise. It is enforcing phishing-resistant MFA in the places where a compromised credential would have catastrophic blast radius, and knowing specifically which those places are.
• Good IAM work is not a team drowning in manual toil. It is using the automation and AI capabilities now available to us to surface dangerous privileges, inform access review decisions, and detect the identity patterns no human reviewer will ever catch at scale, freeing human judgment for the decisions that actually require it.
• Good IAM work is not passing an audit. It is building an identity posture that would survive an attacker who has never read your audit report and does not care about your certification timeline.

The frameworks we operate inside exist because somewhere, at some point, someone’s identity infrastructure failed publicly enough to force a regulatory response. The question I carry into every architecture decision, every policy review, and every control deployment is a simple one: am I building something that prevents that, or am I building something that looks like I prevented it?

The difference between those two things is where real harm lives and where the next regulation is quietly being drafted.

Build identity infrastructure that makes the next compliance framework unnecessary.

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

References

– [1] U.S. Department of Health and Human Services, “Health Insurance Portability and Accountability Act of 1996 (HIPAA),” Public Law 104-191. https://www.hhs.gov/hipaa/index.html

– [2] U.S. Securities and Exchange Commission, “Sarbanes-Oxley Act of 2002,” Public Law 107-204. https://www.sec.gov/about/laws/soa2002.pdf

– [3] European Union, “Regulation (EU) 2016/679 (General Data Protection Regulation),” Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2016/679/oj

– [4] PCI Security Standards Council, “Payment Card Industry Data Security Standard (PCI DSS).” https://www.pcisecuritystandards.org/standards/pci-dss/

– [5] U.S. Department of Justice, AMBER Alert Program, “About AMBER Alert.” https://amberalert.ojp.gov/about

– [6] Krebs, Brian, “Target Hackers Broke in Via HVAC Company,” KrebsOnSecurity, February 5, 2014. https://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company/

– [7] Cybersecurity and Infrastructure Security Agency (CISA), “Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations (SolarWinds),” Alert AA20-352A, December 2020. https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a

– [8] Cybersecurity and Infrastructure Security Agency (CISA) and FBI, “DarkSide Ransomware: Best Practices for Preventing Business Disruption from Ransomware Attacks (Colonial Pipeline),” Alert AA21-131A, May 2021. https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-131a

– [9] Uber Technologies, “Security update,” Uber Newsroom, September 19, 2022. https://www.uber.com/newsroom/security-update/

– [10] Microsoft Security Response Center, “Analysis of Storm-0558 techniques for unauthorized email access,” Microsoft Threat Intelligence, July 14, 2023. https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/

– [11] U.S. Securities and Exchange Commission, MGM Resorts International Form 8-K, September 12, 2023. https://www.sec.gov/Archives/edgar/data/789570/000119312523237814/d551104d8k.htm

– [12] Lambert, John, “Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win.,” GitHub, 2015. https://github.com/JohnLaTwC/Shared

About the Author

Nishad Sankaranarayanan is a cybersecurity executive with 20+ years of experience building and leading enterprise security programs in complex, regulated environments. He serves as Global Director of Cybersecurity at Genuine Parts Company — a Fortune 200, $20B+ global enterprise — where he leads a program spanning workforce and customer identity, cloud security, AI governance, and cyber defense across 17 countries. Previously, he was part of the post-breach security transformation at Equifax, contributing to FedRAMP authorization and NIST 800-53 compliance across a large-scale financial data environment. Nishad holds a CISO Executive Certificate from Carnegie Mellon University, serves on advisory boards for several cybersecurity startups, and founded the Atlanta IAM User Group. He is a recognized speaker at Gartner IAM Summit and Identiverse, a 2025 Constellation Research SuperNova Award recipient for Cybersecurity Leadership, and a three-time Ping Identity Excellence Award winner.

The post Most Regulatory Frameworks are Built on Top of Graves appeared first on IDPro.