In Is Policy-Based Access Control (PBAC) an Authorization Model?, I argued that PBAC gets compared to Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) as if it belonged in the same category, when it actually answers a different question.

RBAC and ABAC describe what data a decision is based on: a role, an attribute. PBAC describes how that decision gets made: through a centralized policy engine instead of logic wired into the application. One is about the shape of the rule. The other is about where the rule lives and who evaluates it.

In my opinion, treating them as competing options is like comparing a recipe to a kitchen.

That distinction attempted to solve one specific confusion, but it left a bigger one untouched: PBAC isn’t the only term that gets misfiled this way.

Mandatory Access Control (MAC) and Discretionary Access Control (DAC) get compared to RBAC and ABAC too, even though they describe who administers the rules, not what the rules look like.

Access Control List (ACL) and Relationship-Based Access Control (ReBAC) show up in the same breath as “authorization models,” but one is arguably a special case of the other, depending on which paper you read.

The terminology around authorization has accumulated for decades across access control research, identity vendors, and standards bodies, and a lot of it answers different questions while using the language of a single one: “what model is this?“

This piece generalizes the model-versus-architecture distinction into a full taxonomy. Instead of asking “which authorization model is this system using?“, I want to ask five narrower questions about any authorization system, answer each one independently, and only then see where familiar labels like RBAC, ABAC, MAC, and PBAC actually land. If the terms stop competing once they’re placed on the right axis, that’s a sign the axes are doing real work.

The Core Problem of Authorization

Authorization answers one question: can this subject perform this action on this object? A user reading a file, a service calling an API, a process writing to a database. Every authorization decision reduces to that same triple: subject, action, object.

In the simplest possible system, there’s no decision to make because there’s no separation between the party asking and the party deciding. Picture your own diary, kept in a drawer in your own room. You want to read it, so you open the drawer and read it. Nobody has to grant you permission, because nobody else is involved: wanting and getting are the same act.

Real systems rarely stay this simple, because the thing being accessed usually belongs to more than one interested party. Put that same diary in a house with housemates, or move it into a company’s filing cabinet, and the picture changes immediately. Not everyone who wants to open the drawer should be allowed to, and somebody has to decide, case by case, who does and who doesn’t.

A resource server does exactly that job for software. A multi-tenant SaaS application, an internal API, a cloud storage bucket accessed by dozens of services: all of them need something that looks at a request and decides whether to honor it. That “something” is what the rest of this piece is about, and it turns out to have more moving parts than a single word like “RBAC” or “PBAC” can capture.

How an Authorization Request Gets Processed

Follow a single authorization request through a resource server and a consistent set of stages emerges, regardless of the specific technology involved: a request arrives, the server gathers context about the user and the resource, a policy evaluates that context against a rule. The evaluation produces an allow or deny decision, and the server enforces that decision by letting the request through or rejecting it.

The same five stages appear in essentially every authorization system:

1. Someone defines the rules. A developer hardcodes a check; a security team writes a policy; a resource owner sets sharing permissions on their own file.
2. The rules take some concrete shape. A conditional in application code; a JSON document; an XACML policy; a row in a spreadsheet someone exports into a database table.
3. Some data has to feed the decision. The user’s role; the department listed in a database; the time of day; the relationship between the requesting user and the resource’s owner.
4. A decision gets computed. The rule and the data get evaluated together, producing allow or deny.
5. The decision gets enforced. Something has to actually act on the result: block the request or redirect it.

These five stages map onto a vocabulary that’s been around in access control architecture for a while:

• Policy Administration Point (who defines the rules)
• Policy Information Point (what data feeds the decision)
• Policy Decision Point (where the decision gets computed)
• Policy Enforcement Point (where it gets enforced)

Brossard’s overview of ABAC architecture lays out this PAP/PIP/PDP/PEP breakdown in more detail, and it’s worth reading if these terms are new.

There’s a related, more academic framing worth pulling in here, from a 2022 systematic literature review of authorization and access control research by Mohamed, Auer, Hofer, and Küng. The paper draws a ladder with four levels: an authorization strategy (discretionary, mandatory, or hybrid) sits above an authorization model (the subjects, objects, and other components a system reasons about), which sits above an authorization policy (the concrete rule instance). In parallel, an access control model (the logic for deciding allow/deny) is enforced by an access control mechanism (the actual running software). It’s a rigorous way of saying the same thing this piece is arguing: strategy, model, policy, and mechanism are separate layers, and conflating them is where the terminology breaks down.

None of these five stages, by themselves, tells you whether a system “is RBAC” or “is PBAC.” Each stage is actually a separate question, with its own independent set of answers. That’s the seed of the classification below.

A Consistent Classification

Six axes cover the five stages above (Authorization Policy gets split from Authorization Model, since a model can be instantiated by more than one kind of concrete policy artifact). Each axis has a small number of common answers, and every familiar term (ACL, RBAC, ABAC, ReBAC, MAC, DAC, PBAC) is really an answer to one specific axis, not a label for the whole system.

A useful way to keep the six axes distinct is a metaphor borrowed from outside software entirely: the machinery of law. A legislature drafts rules, the rules get written down as statutes, courts weigh those statutes against the facts of a case, and police carry out the verdict. Swap “legal system” for “authorization system” and the same six jobs reappear below, one at a time.

Authorization Administration: who sets the rules?

Before a rule can be evaluated, someone has to have the authority to write it in the first place. That authority can be concentrated in one place or spread across many, and a system’s answer here is independent of what the rules actually say. Authorization administration can be:

• Centralized: a security team or administrator defines rules for everyone. This is the pattern behind MAC (Mandatory Access Control): access is determined by a central authority, not by the resource owner.
• Decentralized: the owner of a resource decides who else can access it. This is DAC (Discretionary Access Control): the classic “share this file with these people” pattern.
• Hybrid: some rules come from a central authority, others from individual resource owners, layered together.

Mohamed et al’s literature review treats strategy this way too, and their comparative analysis is instructive: when they classified access control models against this axis, RBAC, ABAC, and ReBAC families all landed in the hybrid category, not cleanly in DAC or MAC. That’s a useful data point on its own. It confirms administration strategy is genuinely independent of authorization model: a role-based system can be centrally administered, owner-administered, or both, and it’s still RBAC either way.

The legal system runs on exactly this split. A parliament, or a king under older systems, legislates for an entire population: centralized administration. Two neighbors agreeing on where a fence line runs, or a homeowner deciding who gets a key, is decentralized administration, closer to how contract law and property law actually work. Most real legal systems mix both, the same way most authorization systems do.

Authorization Model: what data type drives the decision?

Once the authority to write a rule is settled, the next question is what the rule actually reasons about: the specific kind of information a decision checks each time it runs. This is the axis most people mean when they say “authorization model,” and it’s the one my earlier PBAC article focused on. Here are a few common authorization models:

• Identity-based (ACL): the decision checks whether the specific subject appears on a list attached to the object.
• Role-based (RBAC): the decision checks whether the subject holds a role that’s been granted the requested permission.
• Attribute-based (ABAC): the decision checks attributes of the subject, object, action, or environment against a rule (department = “finance”, clearance ≥ “secret”, time between 9 AM and 5 PM).
• Relationship-based (ReBAC): the decision checks the relationship between subject and object, often by traversing a graph (is this user a member of the team that owns this document?).

It’s worth being honest about the fuzziness here. Depending on which academic source you read, ACL and RBAC can be described as special cases of ABAC, where the attribute in question happens to be identity or role membership. These four categories are the most useful cut for a working taxonomy, not a claim that the categories are mutually exclusive at the mathematical level.

The law makes the same kind of distinction between what a rule is actually about. Constitutional and administrative law usually define who may act by office, “only the president may sign this treaty“, which is role-based. Regulatory law more often reaches for attributes, “any business with revenue over ten million dollars must file this report“. Family and contract law hinge on a relationship: spouse, parent, business partner. And a law or injunction naming one specific person or company is the legal equivalent of an ACL. Different areas of law reach for different criteria for the same reason different authorization systems do: each criterion fits a different kind of decision.

Authorization Policy: what shape does the rule take?

Once a model is chosen, it still has to be written down somewhere as a concrete artifact:

• Hardcoded conditionals in application code.
• A structured document (JSON, YAML) loaded and interpreted at runtime.
• A declarative policy language purpose-built for authorization, like XACML, Rego (Open Policy Agent), or Cedar.
• A row in a database table.

This axis matters because two systems can share the same authorization model (both are RBAC) while differing completely in maintainability, auditability, and who’s allowed to change the rules, purely because of how the policy is expressed.

In the legal metaphor, this is simply the law itself: the actual text of the statute or code, independent of who passed it and independent of which area of law it belongs to.

Authorization Information: where does the decision-relevant data come from?

A rule is only as good as the data it’s evaluated against, and that data doesn’t all arrive the same way. It’s worth separating what the rule depends on from how the system actually gets its hands on it:

• Wired in: the data is already available in the application’s normal request flow, no extra lookup required.
• Token-based: the data arrives as claims in a JWT or similar credential, populated by the identity provider at issuance time.
• Looked up: the application queries a database, directory, or external service at decision time.
• Environmental: the data describes the context of the request itself rather than the subject or object: time, location, device posture, network.

This is a place where even careful academic treatments blur a real distinction. Mohamed et al’s framework folds environmental attributes into the authorization model’s component list, alongside subjects and objects, rather than treating “where does this data physically come from at runtime” as its own architectural concern. I think that’s a small version of the same mistake the PBAC article calls out: knowing that a decision depends on “time of day” is a modeling question but knowing that the request has to make a network round-trip to a directory service to get it is an architecture question, with real consequences for latency and failure modes.

A courtroom depends on the same kind of input: facts and events. Testimony, documents, timestamps, prior records. The same law applied to a different set of facts produces a different verdict, exactly the way the same policy applied to different token claims or different database lookups produces a different authorization decision. And, just as in an authorization system, where those facts come from (a witness on the stand, a document requested via subpoena, or an expert report) is its own separate concern from what the law says.

Authorization Decision: how and where is the decision computed?

Once a rule and its data are both available, something has to actually run the evaluation. That “something” can live in a few different places, and where it lives is a question about architecture, not about the rule itself:

• Wired into application code: an if statement or a framework-native permission check inline with the business logic.
• A dedicated library or module: decision logic factored out but still running inside the application process.
• A centralized policy engine: a separate service that receives context and returns a decision, often shared across many applications.

PBAC lives here, not on the “authorization model” axis. Centralizing the decision point into a policy engine is an architectural choice about where evaluation happens, and it’s compatible with any of the authorization models: a PBAC engine can evaluate role-based rules, attribute-based rules, or a mix. That’s exactly why PBAC isn’t a peer of RBAC and ABAC. It’s an answer to a different question than the one RBAC and ABAC answer.

This is where the courtroom metaphor lands squarely: a court, and specifically a judge, is the decision engine. The law and the facts go in, a verdict comes out. And a legal system’s habit of routing different kinds of cases to different, specialized courts (traffic court, family court, a supreme court) without changing what the underlying law says is a good picture of what PBAC actually is. It’s a choice about which court hears the case, not a change to the law itself.

Authorization Enforcement: how and where is the decision enforced?

A decision only matters if something acts on it, and that action doesn’t have to happen in the same place the decision was made. Authorization enforcement can live in:

• Wired into application code: the same code path that made the decision also acts on it.
• Dedicated middleware: a framework-level component intercepts the request based on the decision.
• Distributed enforcement: a gateway, sidecar, or proxy enforces decisions at the network edge, independent of the application itself.

Like the authorization decision axis, this is architecture, not model. A system enforcing ABAC decisions through an API gateway and a system enforcing ABAC decisions through inline middleware are both, unambiguously, ABAC. They just made different choices about where enforcement lives, usually driven by concerns like operational scale or the number of services that need to share one policy.

This is the police, in the metaphor: the verdict gets carried out regardless of whether that happens inside the courtroom or on a street corner miles away. The court decides; the police act. It’s the same separation between authorization decision and enforcement in an authorization system.

Putting it together

A real authorization system’s full description is a tuple across all six axes, not a single word. “RBAC” says something about the authorization model axis and nothing about the other five axes. An authorization system can have:

• Centralized administration (MAC)
• Role-based model (RBAC)
• JSON policy documents
• Token-based information
• A shared policy engine (PBAC architecture)
• Gateway-level enforcement.

That’s a coherent, common real-world setup, and every label in it is accurate simultaneously, because each one answers a different question. The confusion in most authorization discussions comes from picking one label per system and treating it as exhaustive, when it’s really just the answer to whichever axis happened to come up first in the conversation.

The legal metaphor running through this section is useful precisely because it breaks down in the same places the software terminology does. Nobody would call a law court an “administrative law” or claim the existence of a “witness-based law” because a judge renders a verdict considering the deposition of a witness. But the six jobs underneath it (who legislates, what kind of law applies, what the law actually says, what facts it’s applied to, who judges, who enforces) are as separable in a courtroom as they are in a policy engine, and confusing them causes the same kind of category error either way.

Conclusion

The terminology problem in authorization isn’t that the field lacks vocabulary. If anything, it has too much: MAC, DAC, RBAC, ABAC, ReBAC, ACL, PBAC, and more, each coined by a different paper, standard, or vendor, at a different layer of the same request lifecycle. The problem is a habit of treating all of it as one flat list of “authorization models” to choose between, when most of these terms don’t compete with each other at all.

Separating the questions helps in a very practical way when you’re actually choosing an approach for a real system: pick the authorization model based on what your access rules naturally depend on (roles, attributes, relationships). Separately, pick the architecture (where decisions get made and enforced) based on your operational constraints (how many services need to share policy, how much latency you can tolerate, who needs to audit or change rules). Those are two separate decisions with two separate sets of tradeoffs and bundling them into a single choice (“we’re doing PBAC” or “we’re doing RBAC“) tends to hide half of what actually needs deciding.

None of this makes the individual labels wrong. RBAC is a real, useful description of a model. PBAC is a real, useful description of an architecture. They’re just not describing the same thing, and a consistent classification is what lets you say precisely which thing each one is.

References

• Is Policy-Based Access Control (PBAC) an Authorization Model?
• A Taxonomy of Modern Authorization Models
• The State of the Union of Authorization
• A systematic literature review for authorization and access control: definitions, strategies and models. International Journal of Web Information Systems, 18(2/3), 156-180. https://doi.org/10.1108/IJWIS-04-2022-0077

Andrea Chiarelli is a Principal Developer Advocate at Auth0 (Okta). He has extensive experience in software development, holding various technical roles. In recent years, he has focused on Identity, developing a passion for the core concepts, which he aims to disseminate to developer communities.

The post Authorization Terminology is a Mess: Let’s Fix It appeared first on IDPro.

IDPro and Identiverse have always had a close relationship. IDPro was formally launched at Cloud Identity Summit 2017 in Chicago (the same year we announced the rebrand to Identiverse) with a main stage talk by Ian Glazer and Sarah Cecchetti; for several years after, the two organisations maintained a semi-formal agreement, identifying Identiverse as the ‘home event’ of IDPro. Eventually, that agreement was allowed to lapse—it really wasn’t needed anymore, given the depth of engagement IDPro members have with the event.

The relationship shows up in a number of ways—informal gatherings, formal IDPro events, discount codes, constructive feedback from the community to the organisers, and much more besides…. But nowhere is it as apparent as in the responses we get from IDPro members to the annual Call for Presentations (“CFP”).

The core of the Identiverse agenda revolves around sharing leading practices: “here’s a problem I ran into, here’s how I solved it” (or sometimes “here are solutions I’m considering”). Who better than IDPro members to provide those kinds of perspectives?  Every year, the CFP is advertised via IDPro Connect Slack. Every year, I see ever more draft proposals being shared, ideas being floated, and advice being sought.

In case you didn’t know, nigh on 80% of the main Identiverse agenda comes through the CFP. We’ve had nearly two decades to refine the review and selection process; and whilst it will never be perfect—and is consequently the subject of routine, incremental review and improvement, even today—we have over that time established, tested, refined, and in some cases entirely replaced, a range of mechanisms that help us to ensure a fair process which ultimately results in a comprehensive and balanced agenda.  (If you’d like to know more, I’ve previously written in more detail about the agenda-building process in “The Art and Science of Agenda Building”, at https://www.hindleconsulting.com/posts/agenda_building/)

Identiverse—like IDPro—is also growing rapidly, in lockstep with a profession and an industry that are increasingly understood together as a (the!) vital enabler of the digital landscape. Partly as a result, we receive many more proposals every year than we can possibly accommodate on the agenda—for the 2026 CFP, by a factor of 5 —and we expect this will only increase in the coming years.

It’s at this point that people often ask me, “Well, if my chances are so slim, why should I propose?”  And to that question, I have several answers!  First: the act of preparing and submitting a proposal is, in and of itself, useful work. It can help refine and focus ideas; it can lead to new revelations or approaches to consider and discuss with others; and it’s a good way to sharpen the skills of distilling and clearly communicating complex concepts. On that latter point: yes, AI tools can help (although don’t feel that you have to, or even that you should use LLMs for this kind of work: they are just tools!): but only if given clear prompts to start with, and with careful editing and iteration during the process… and those are great skills to hone, too.

Even if your proposal isn’t accepted, it will be read and reviewed, which in turn helps inform the committee as to what matters topically to the community. That contribution, invisible to you though it may be, is nonetheless hugely influential in the development of the conference agenda, year after year.

You may, of course, choose to submit your proposal to several events, getting more than one-time use from your work. (Authenticate is another identity-focused conference that operates a very similar process to Identiverse, and is worth your consideration. There are others, too!)  Exercise some caution when you do this: several conferences ask whether your talk has been submitted to, or delivered at, other events. Don’t make assumptions about why that question is being asked: sometimes (as for Identiverse) it’s simply another data point for the committee. Do answer honestly—any conference that operates a rigorous process like Identiverse will easily find out if you mislead, and that can absolutely affect selection chances in future years!

But perhaps the most compelling reason is this: submitting a proposal to speak provides no guarantee whatsoever that your talk will be selected. But it’s a cast-iron certainty that your proposal cannot be selected if you don’t submit it!

The Identiverse 2027 Call for Presentations will open in October. Keep your eyes open for when it does. Talk to your colleagues, your friends, your peers. Get advice from the IDPro community about how to refine your proposal. And then get your work in front of the committee. It’s one of the best ways to contribute to the profession that I can think of.

About the Author

Andrew Hindle is an independent consultant and board advisor with deep expertise in digital identity, privacy, cybersecurity, and corporate governance, built across 25+ years in the global software industry. He works with boards, executives, and founders to navigate growth, risk, and strategic change in complex, fast-paced environments.

Andrew currently serves as a Non-Executive Director at Curity; as a board member at Women in Identity; and as Chair of the UK Advisory Board at the Kantara Initiative. He is a co-founder of The Identity Salon, and Conference Chair for Identiverse and Authenticate, where he works closely with industry leaders to curate high-quality, practitioner-focused content for the digital identity community. Andrew is also a Board Emeritus at IDPro, of which he was a founding member.

The post Symbiosis: Identiverse and IDPro appeared first on IDPro.

Part 3 of 3

By Vidyaa Ganesh

This is Part 3 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. Part 2 examined the frameworks currently available and the structural reasons no standard has emerged. This final installment proposes what a credible standard would need to include.

If the IAM community is going to move toward standardized measurement, what would a credible framework need to look like? Based on the published research reviewed in this series, established precedent from other domains, and the practical needs of practitioners, seven design principles emerge.

Principle 1: Domain Decomposition, Not Monolithic Scoring

IAM is not one thing. A useful maturity framework must decompose the discipline into distinct domains and assess each independently before producing any aggregate score. Treating IAM as a monolith obscures critical gaps. An organization with excellent identity governance but absent privileged access controls has a fundamentally different risk profile than one with moderate capabilities across the board, even if their aggregate scores are identical.

Gartner’s six-dimension structure is a reasonable reference point for domain decomposition. At minimum, a framework should separately assess identity lifecycle management, access management and authentication, privileged access management, and governance. Depending on the organization’s context, customer identity, cloud identity, and identity threat detection may also warrant distinct assessment.

Principle 2: Foundational Prerequisites Must Gate Advanced Claims

This may be the single most important design principle. A framework must account for the reality that some IAM capabilities are prerequisites for others. An organization that has deployed sophisticated analytics and AI-driven threat detection but has not implemented basic multi-factor authentication on privileged accounts has a fundamentally flawed security posture. A credible maturity score should reflect that.

This principle is well-established in adjacent fields. CMMI’s staged representation explicitly requires lower-level process areas to be satisfied before higher-level ratings can be claimed. SailPoint’s Horizons framework states that to be placed in a given horizon, capabilities must cover most environments and identity types. CISA’s Zero Trust Maturity Model states that identity pillar capabilities must be established before device trust can be meaningful.

A standardized IAM framework should identify a limited set of foundational controls and ensure that gaps in those controls are reflected in the overall maturity score. Without this, organizations can game the assessment by investing in visible, advanced capabilities while neglecting the basics that actually prevent breaches.

Principle 3: Risk-Weighted Scoring

Not all IAM controls carry equal risk. The presence or absence of MFA on privileged accounts has a materially different security impact than the presence or absence of a formal identity data classification scheme. A credible framework must reflect this through some form of risk-weighted scoring.

Published research supports this approach. IBM’s 2025 data shows that organizations with extensive security automation experienced average breach costs of $3.62 million compared to $5.52 million without, a 34% cost reduction attributable to mature controls. Microsoft’s Digital Defense Report found that MFA blocks over 99% of account compromise attacks. The data makes clear that certain controls deliver disproportionate risk reduction and should be weighted accordingly.

Principle 4: Industry-Contextualized Benchmarks Derived from Empirical Data

A maturity score in isolation is nearly useless. What makes it actionable is context: how does this score compare to others in the same industry, of similar size, facing similar regulatory requirements? A credible framework must include an empirical benchmark layer.

The data for this already partially exists. SailPoint publishes industry breakdowns. Ponemon publishes breach cost data by industry. Simeio publishes maturity scores by vertical. What does not exist is a single, consistent benchmark set that covers all IAM domains across major industries. Building this requires either a large-scale survey effort or, more practically, the aggregation of assessment data across organizations over time, with appropriate anonymization and consent.

Principle 5: Transparency of Methodology

Every number in a maturity assessment should have a documented derivation. If a domain receives a higher weight than another, the rationale should be published. If a benchmark is based on a specific data source, that source should be cited. If a benchmark is estimated rather than measured, that should be disclosed.

This level of transparency is uncommon in commercial assessment tools, where scoring logic is often proprietary. But for a community standard, it is essential. Consultants need to be able to explain and defend the numbers they present to clients. CISOs need to trust that the methodology is sound before presenting results to their boards. Transparency is not just a nice-to-have. It is a prerequisite for adoption.

Principle 6: Technology Agnosticism

A standardized framework must assess capability, not tooling. The question is not whether an organization has deployed a specific vendor’s IGA platform, but whether it has a functioning identity lifecycle management process that covers joiners, movers, and leavers with appropriate automation and oversight. This distinction matters because organizations achieve similar maturity outcomes with very different technology stacks, and a useful standard must accommodate that diversity.

Principle 7: Actionable Outputs

A maturity assessment that produces only a number is insufficient. The assessment process should produce outputs that enable direct action: identification of specific capability gaps, prioritized remediation guidance, regulatory compliance mapping, and clear criteria for what moving from one level to the next requires.

Gartner’s recommendation of outcome-driven metrics for IAM aligns with this principle. The goal of measurement is not the score itself but the improvement roadmap it enables. A framework that scores but does not guide action is an academic exercise.

Gaps and Open Questions

Even with sound design principles, significant gaps remain that the community will need to address.

Non-human identity. Machine identities (service accounts, API keys, certificates, workload identities) now outnumber human identities by ratios that CyberArk’s 2025 research places at approximately 80 to 1. Yet most maturity models treat identity as synonymous with human identity. A credible standard will need to account for non-human identity management as a distinct assessment domain.

AI agent governance. As AI agents increasingly operate autonomously within enterprise environments, the question of how to govern their identities, permissions, and access patterns is emerging as a new challenge. SailPoint’s 2025 Horizons research added AI agent governance to its capability thresholds. No existing maturity model addresses this domain in depth. Any framework designed for longevity should be extensible enough to incorporate it.

The data collection problem. The most practical path to building reliable industry benchmarks is through the aggregation of anonymized assessment data across many organizations over time. This creates a chicken-and-egg problem: organizations are reluctant to contribute data to a benchmark pool unless the benchmark already exists, and the benchmark cannot exist without contributed data. Solving this will likely require a combination of opt-in data sharing, strong privacy guarantees, and a trusted neutral party to manage the aggregation.

Weighting validation. Any risk-weighted scoring system involves judgment calls about how much weight to assign to different controls and domains. These weights can be informed by published research on breach costs, attack frequency, and control effectiveness, but they cannot be fully derived from first principles. Ongoing validation through correlation analysis between assessment scores and actual security outcomes is needed to refine the weights over time.

Conclusion

The IAM community has a measurement problem. Five independent research sources, covering over 2,000 respondents, consistently show that 60% to 70% of organizations are at early-to-mid stages of IAM maturity. At the same time, the industry relies on a fragmented set of incompatible frameworks that prevent meaningful comparison, benchmarking, or progress tracking.

This is not a technology problem. The tools exist. This is a standards problem. The community lacks a shared, vendor-neutral, empirically-grounded framework for measuring IAM maturity, and the absence of such a standard has real consequences: CISOs cannot articulate their posture to boards in comparable terms, consulting firms deliver assessments that start from scratch with each engagement, and the industry has no aggregate data pool that could identify systemic weaknesses and drive collective improvement.

The design principles outlined in this series are not radical. Domain decomposition, foundational prerequisite gating, risk-weighted scoring, empirical benchmarks, methodology transparency, technology agnosticism, and actionable outputs are all well-supported by existing research and established practice in adjacent disciplines. What is missing is the will to build and adopt a standard that incorporates them.

Identity practitioners are the people best positioned to solve this. They live the problem daily. They understand the domains. They see the consequences of unmeasured and unmeasurable IAM programs. The question is whether the community will continue to tolerate a landscape where every assessment is a one-off, or whether it will converge on a shared approach that raises the bar for everyone.

About the Author

Vidyaa Ganesh is a Senior IAM Engineer and Team Lead at Raah Technologies, with over six years of experience spanning enterprise IAM implementations, strategic advisory, and maturity assessments. She has held consulting roles at KPMG Canada and Indigo Consulting, delivering identity governance and privileged access programs for financial services, energy, telecommunications, and public sector clients. She holds Okta and Saviynt certifications and a Master of Engineering from Concordia University. She is a member of IDPro.

Endnotes

17. Gartner, IAM Program Maturity Model (September 2025).

18. ISACA, CMMI Version 3.0: “A maturity level rating is achieved when all process areas at that level have been appraised as meeting their specific and generic goals.”

19. SailPoint, Horizons 2025-2026: “To be in one horizon, customer capabilities need to cover most environments and identities.”

20. CISA, Zero Trust Maturity Model (2023).

21. IBM Security, Cost of a Data Breach Report 2025.

22. Microsoft, Digital Defense Report (Microsoft Security, 2024).

23. NIST, SP 800-30 Rev 1: Guide for Conducting Risk Assessments (2012). See also FAIR Institute.

24. SailPoint, Horizons 2025-2026, Exhibit 7.

25. IBM Security, Cost of a Data Breach Report 2025, Industry Analysis section.

26. Simeio, State of Identity 2024.

27. Gartner, IAM Program Maturity Model (September 2025). Recommends outcome-driven metrics (ODMs).

28. CyberArk, The Urgent Reality of Machine Identity Security in 2025 (CyberArk, 2025), 2,600 decision-makers.

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 What Good IAM Measurement Looks Like appeared first on IDPro.