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.

IETF 124, November 2024. Montreal was cold outside, the discussions inside were heated. AI agents were the topic on everyone’s lips, and every working group seemed to be looking at the problem through their own lens. The WIMSE folks were thinking about workload identity. The OAuth crowd was extending grants and tokens. SPIFFE was already deployed in production for service mesh identity. And the Agent2Agent BOF and WebBotAuth WG were trying to address the same topics through their own lens.

The identity community had spent the better part of two decades building a robust, battle-tested toolkit for authentication, authorization, delegation, and observability. OAuth 2.0, SPIFFE, WIMSE, Transaction Tokens, Shared Signals, OpenID Connect. This stuff works. It’s deployed at planet scale. And yet, every new “agent identity” proposal we were seeing started from first principles, reinventing token formats, credential lifecycle, even basic concepts like “what is a workload identity.”

Quickly we sat down with Pieter Kasselman, pointing at the elephant in the room: we don’t have a standards gap. We have an assembly gap. With the support of Brian Campbell, Nick Steele, Yaroslav Rosomakho, and Aaron Parecki, this thinking became draft-klrc-aiagent-auth, now at version -03. A personal Draft that introduces a simple but strong conceptual model called AIMS (Agent Identity Management System).

The thesis: agents are workloads

The core argument is deceptively simple: an AI agent is a workload. It needs an identifier. It needs credentials. It authenticates to other systems. It requests authorization. In short, something the industry has been solving for services, containers, and microservices for years.

Still, what makes agents operationally different is the risk profile:

Dynamic action surface. An agent doesn’t have a fixed API contract. It decides at inference time which tools to call, in what order, based on reasoning that didn’t exist when the agent was deployed.

Cross-domain by default. A single agent task routinely spans internal services, third-party APIs, other agents; each in different trust domains.

Time sensitive and high-churn. Agent instances spin up, fan out, terminate. Some are long lived, running for hours or days, most are short lived, running for seconds or minutes.

High-value targets. An agent with not-contextualized or not-bound credentials is essentially a privileged insider with no audit trail.

What AIMS actually does

AIMS defines a layered stack where each layer is built on guarantees from the one below. There’s no single solution to all of this: it takes a wide range of technologies covering identifiers, authentication, authorization, delegation, and monitoring. What didn’t exist before was the organizing framework that ties them together.

Here’s how it breaks down:

Identifiers. Foundation for everything. The draft proposes WIMSE identifiers (a superset of SPIFFE IDs). A URI that uniquely identifies the agent workload.

Credentials. Authentication and authorization rely on credentials that cryptographically bind identifiers to agents, instead of bare identifiers or long-lived secrets like API keys. The WIMSE credentials specification (X.509 certificates and Workload Identity Tokens) fits well here, along with SPIFFE JWT-SVIDs. Cryptographic proof of ownership of the identifier.

Provisioning. SPIFFE for the general case, while leveraging platform-specific mechanisms (MDMs for end-user posture assessment, cloud-native posture evaluation) depending on where the agent runs.

Authentication. Agents authenticate to LLMs, tools, services, resources, other agents. The draft maps WIMSE credential mechanisms with mTLS at the transport layer and HTTP Message Signatures, WIMSE Proof Tokens at the application layer. The through-line: avoid static pre-shared credentials, it’s an anti-pattern.

Authorization. Specifically, delegated authorization through OAuth. What an agent can access, whether it’s acting on behalf of a user or on its own, how end-users authorize agents to act on their behalf. The draft maps the existing OAuth specs to specific agent use cases: authorization code flow for delegated user flows, client credentials for autonomous agents, token exchange scope and authorization details management, identity chaining via ID-JAG for multi-domain workflows and leaves a space for policy based authorization which may be facilitated through AuthZEN and other policy based authorization standards

Observability and Remediation. Risk evaluation changes. Authorization may need to change mid-session. How do you propagate that? The OpenID Foundation’s prior work here is directly applicable: Shared Signals Framework (SSF), CAEP for continuous access evaluation, RISC for account-level signals. Audit critical details, revoke credentials, trigger re-evaluation.

Policy and Compliance. What are the rules? How do you measure against them? This is inherently deployment-specific. The draft deliberately doesn’t point to any single policy standard here, leaving room for organizations to fit their existing infrastructure in.

Every single component in that stack is either an existing RFC, a mature IETF draft, or an OpenID specification that’s already deployed in production somewhere. The draft doesn’t define any new wire protocol. It profiles and composes.

The constraints that motivated us

Through this work, we set ourselves a few constraints early:

If it exists and works, use it. Don’t reinvent credential formats. Don’t create yet another token type. Don’t define a new discovery mechanism when OAuth Server Metadata and Protected Resource Metadata already exist.

If something is genuinely new, call it out as a gap. The draft explicitly identifies areas where profiles, extensions, or new work is needed. Human-in-the-loop mid-execution authorization is one: CIBA gets close but the message flow and client initiation model don’t map well to an agent needing approval during execution, not before. That gap has already produced a new draft (more below). Cross-domain use of transaction tokens is another. Dynamic client relationship management proved DCR was not the end goal, the emergence of CIMD was helpful.

Don’t solve the deployment architecture. AIMS is a conceptual model, not a product spec. It might be one component or distributed across identity providers, authorization servers, policy engines, and runtime enforcement points. That was intentional as it has to map to real deployments that already look different from each other. 

The ecosystem is moving

This is the part that gives me optimism. The framework isn’t just a document; it helped catalyzing focused work on the specific areas where profiles and extensions are genuinely needed. It proved people aren’t reinventing but they’re extending precisely where the existing tire doesn’t fit the road.

The market started validating the thesis of the draft independently. Sean O’Dell, Distinguished Engineer at CVS Health and now a co-author on the Transaction Token Chaining Profile, published “You Already Have the Pieces. Now Build It.” on The Identity Underground. It’s worth reading in full. He opens with the same observation we built the draft around.

OpenAI, Anthropic, and Snowflake have all shipped Workload Identity Federation endpoints  using OIDC and SPIFFE-style credentials to authenticate workloads against their platforms without static API keys. This is literally the AIMS model landing in real systems. The theory is catching up to what practitioners are already doing, and vice versa.

Finally, new proposals have come out of this work:

OAuth Transaction Authorization Challenge by Yaroslav Rosomakho, Brian Campbell, Karl McGuinness, and Pieter Kasselman tackles head-on the human-in-the-loop gap we identified. CIBA’s message flow doesn’t map well to mid-execution approval as it’s client-initiated, not resource-driven. This draft flips it: the protected resource issues a signed challenge when a specific operation requires additional authorization; the agent relays the challenge to a client, which presents it to an authorization server that obtains approval and issues a transaction-scoped access token. It reuses OAuth’s existing capabilities.

Transaction Tokens for Agents by Ashay Raut extends the Transaction Token specification with agent-specific semantics through the act claim for identifying the agent performing the action, and an agentic_ctx claim for conveying operational constraints relevant to authorization, auditing, and policy evaluation within the service graph.

Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining by George Fletcher, Pieter Kasselman, and Sean O’Dell defines how a Transaction Token scoped to a single trust domain can be used as an authorization grant to obtain a JWT Authorization Grant for crossing a trust boundary. This is what makes cross-domain multi-agent workflows practical without requiring every authorization server to trust every other one directly.

WISE: Workload Identity Security Events by Dag Sneeggen, Sean O’Dell, Pieter Kasselman, and myself profiles the Shared Signals Framework for workload identity lifecycle events. SSF, CAEP, and RISC solved the human identity signal story, and WISE extends the same asynchronous event model to workloads: credential rotation, trust revocation, posture changes, and the security state transitions that arise when agents act on behalf of humans, on behalf of other agents, or autonomously. It builds on RFC 8417 (SET), the WIMSE identifier and credential specifications, and the CAEP Interoperability Profile patterns.

All of these are exactly the kind of focused, incremental work that the AIMS framework was designed to surface as missing.

What this means for practitioners

If you’re an identity architect or an IAM practitioner reading this, here’s the takeaway: you already have most of what you need to secure agentic workloads. The standards are written. The protocols are mature. What’s been missing is the map showing how they connect as well as the clarity on where the gaps actually are.

That’s what AIMS provides. And where the map shows blank spots, the community is filling them in with targeted, interoperable specifications rather than competing greenfield stacks.

We’re heading into IETF 126 in Vienna later this month. The AIMS draft is already shaping the standards landscape. I expect to have more exciting updates as those meetings wrap up. In the meantime, the pieces are on the table. Time to assemble.

About the Author

Jeff Lombardo is a Principal Identity Specialist at AWS based in Montreal. He contributes to IETF and OpenID Foundation work on identity architecture for agentic systems. The views expressed here are his own.

The post Assembly Required: How we Stopped Reinventing and Started Composing Standards for Agentic Identity appeared first on IDPro.