Since 2017, IDPro® has been growing, evolving, and supporting the professionals working in the field of digital identity. From our founding to launching CIDPRO®—Certified Identity Professional—in 2021, we’ve worked to build a strong, connected IAM community.

Now, it’s time to welcome a new leader to help shape IDPro’s future. With the board size set at nine members, we have open seats for an engaged and enthusiastic professional to join us in July 2026.

What It Means to Be on the IDPro Board

This isn’t a ceremonial role—it’s hands-on. IDPro’s board is operational, which means rolling up your sleeves to keep things moving. Board members typically contribute 10–15 hours per month, participating in monthly meetings, managing projects, and engaging with members.

If you’re passionate about the practice and the profession of digital identity and want to actively contribute to the success of IDPro, we’d love to see you throw your hat in the ring.

As a board member, you will:

Help steer IDPro’s strategic direction

Unlock new opportunities for members through sponsors
Support financial health and organizational growth
Strengthen the IAM community and professional network
Work alongside industry leaders and practitioners
Gain leadership experience and visibility in the field

We value collaboration, inclusivity, and diversity—and we encourage identity professionals from all backgrounds to apply.

Ready to Nominate?

If you or someone you know would be a great fit, now’s the time to act! Self-nominations are welcome—after all, who knows your passion and skills better than you?

To apply, email director@idpro.org for the nomination packet.
Deadline for completed nominations: May 15, 2026.

This is your chance to make a real impact in the world of digital identity. We can’t wait to see who steps forward!

The post Join the IDPro Board appeared first on IDPro.

This article is written from one reference point only:

How identity actually behaves inside modern production systems. Not how we document it, not how tools describe it, and not how access reviews assume it works.

When you look at identity from that lens, a quiet but fundamental shift becomes impossible to ignore.

Identity is no longer just a security layer.

It is becoming the operating system of the modern enterprise.

The Shift No One Announced

There was no roadmap presentation.

No architectural review.

No executive decision.

Yet over the last decade, identity has absorbed responsibilities that operating systems traditionally owned:

• Deciding who can execute
• Deciding when execution is allowed
• Brokering trust between components
• Enforcing policy at runtime
• Orchestrating automation
• Gating system state changes.

Today, almost every critical action in an enterprise is mediated by identity:

• Code reaching production
• Infrastructure being created
• APIs being called
• Data being accessed
• Privileges being delegated.

Remove identity and systems don’t slow down; they stop functioning.

That’s the definition of an operating system.

Identity No Longer Just Answers “Who”

Classic IAM was built to answer one question

Who are you?

Modern identity systems answer a very different set of questions:

• Is this action allowed right now?
• Under what conditions?
• From which environment?
• Triggered by which workflow?
• With what downstream impact?

Conditional access, workload identity, CI/CD pipelines, and policy engines have quietly turned identity into a decision runtime.

Identity now schedules work.

Identity now gates execution.

Identity now brokers trust between machines.

This is not an access control problem anymore.

It’s a control-plane problem.

Why This Matters: OS Level Failure Modes Are Different

When an application fails, it crashes.

When infrastructure fails, it degrades.

When an operating system fails, something worse happens:

It behaves incorrectly while still running.

Identity failures increasingly look like this:

• Nothing is “down”
• No secrets are leaked
• Yet authority moves in ways no one intended.

A pipeline deploys more than expected.

A workload gains transitive trust.

A service identity propagates farther than designed.

This is not misconfiguration.

This is emergent behavior.

And emergent behavior only appears at system scale.

Non-Human Identities: The Processes of This OS

In operating systems, users don’t do the work.

Processes do.

Non-human identities are the processes of modern enterprises.

They include:

• CI/CD pipeline identities
• Workload and service identities
• API integrations
• Automation frameworks
• SaaS-to-SaaS connectors.

They don’t authenticate to log in.

They authenticate to execute continuously.

And increasingly, they:

• Create infrastructure
• Modify policies
• Deploy to production
• Move data across trust boundaries.

In other words they don’t just use the system; rather, they shape it.

CI/CD Pipelines: Kernel-Level Privilege, Quietly Granted

If identity is becoming the operating system, CI/CD pipelines are operating with kernel-level authority.

A mature pipeline can:

• Modify source code
• Deploy infrastructure
• Inject secrets
• Assume cloud roles
• Create or modify IAM policies
• Spin up new identities automatically

And yet, pipelines are rarely modeled as privileged identities.

We audit developers.

We review pull requests.

But once code enters automation, trust expands dramatically.

The pipeline doesn’t ask should this change exist.

It asks is this change valid.

That distinction matters.

The Uncomfortable Truth: Identity Risk Is Emergent

At OS scale, risk is rarely tied to a single control failure.

It emerges from:

• How identity decisions compose
• How trust propagates
• how automation chains together

No individual policy looks wrong.

No single tool is broken.

Yet the outcome is unsafe.

What Professional Are Starting to Do Differently

They are changing how they design.

1. They Model Identity Flows, Not Just Permissions

They ask

• Where does authority originate?
• How does it propagate?
• Where does it become irreversible?

2. They Treat Non-Human Identities as Platform Components

Identities have

• Ownership
• Versioning
• Lifecycle expectations
• Decommission paths

3. They Design for Blast Radius, Not Prevention

They assume

• Misuse will happen
• controls will fail

The Future: Identity-Native Architecture

We’ll see

• Identity treated as runtime infrastructure
• CI/CD pipelines as governed control planes
• Policy evaluated as execution logic
• Assume misuse replacing Assume breach

This isn’t about zero trust.

It’s about system trustworthiness.

The Paragraph That Changes the Frame

We don’t run modern enterprises on operating systems alone. We run them on identity systems.

Identity schedules work, enforces policy, brokers trust, and gates execution. When identity fails, systems don’t go offline but they behave incorrectly at scale.

Closing Thought

Secrets management tells us how securely an identity authenticates.

CI/CD pipelines determine how far that identity’s authority can travel.

The organizations that succeed won’t be the ones with the strongest secrets, they’ll be the ones that design identity so its authority degrades gracefully instead of compounding silently.

One-Line Takeaway

Identity is no longer a security layer. It’s the operating system your business now runs on.

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

Author

Malhar Vora is a Principal Security Engineer and Engineering & People Leader at ANZ Bank with nearly two decades of experience in identity and privileged access security within highly regulated financial environments.

He leads the solution and engineering delivery of enterprise-scale PAM platforms across on-premises and multi-cloud ecosystems, with a focus on systemic risk reduction and resilient identity controls.

Malhar mentors security engineers and collaborates closely with enterprise architecture, cloud, and risk teams to advance modern identity engineering practices.

He is a CyberArk MVP, frequent industry speaker, and active contributor sharing practical insights on identity-centric security and privilege risk management.

The post Identity Is Becoming the Operating System of the Modern Enterprise appeared first on IDPro.

Users also make well-intentioned decisions.  They might need to log into a service from a place thousands of miles away from where they normally do in order to change plans.  They might try to perform what would otherwise be a valid operation during a time that they simply have never been logged on over years of steady use.  They might need to force an old device, now in the hands of an abuser, to be logged out of the service – and do so rapidly.  

Users entrust us with their data.  For a given CIAM service, compromise of an account created by a user may disclose PII, allow for adverse financial transactions to occur on behalf of the user, use the service in a manner that the user may find objectionable or otherwise is against terms of service, and so on.  It behooves us as stewards of a user’s data to ensure compromise does not occur, but at the same time ensure that if the user does what humans do and makes a mistake that they are able to recover gracefully.

With all of that in mind, there comes a point where the actions of a well-intentioned but clumsy user may look not unlike a threat actor who has compromised a user’s account.  It becomes extremely difficult to determine the reality of the situation without having significant context.  A prudently designed system might restrict or otherwise lock users who demonstrate suspicious activity – likewise, a user who suspects their account may be compromised (because they can’t log in suddenly, for instance) may wish to take some actions to prove the account is theirs and kick out anyone else who may be using the account.

A well-designed service should offer a set of mechanisms by which a user may attempt to regain logical access.  Today, these account recovery flows are often highly automated, requiring specific information or actions from the user and minimal intervention from support staff for the service.  This becomes a blessing and a curse, as a savvy attacker may be able to lock out a user and then leverage the account to perform nefarious deeds.

We are then faced with a monstrous task.  How then should we model account recovery so that it rebuffs attackers?  It turns out that recently some interesting answers were shared on this very topic.  During the summer of 2025, Sid Rao and Gabriela Sonkeri gave a talk at Black Hat titled Lost & Found: The Hidden Risks of Account Recovery in a Passwordless Future that offers an auditing framework for account recovery called the ARTHA framework.

The repository that contains the ARTHA framework can be found at https://github.com/Nokia-Bell-Labs/Account-Recovery-Threat-Heuristic-Auditing-Framework .  The auditing process is across 9 separate test cases, which test the following:

• Account creation
• Account state specific tests (how can we recover from different paths in an account recovery flow?)
• How recovery works with multiple recovery methods in play
• Session termination
• The usage of MFA in the flow
• Interchangeability of authentication factors / recovery channels

On top of the framework, the slides from the presentation (https://i.blackhat.com/BH-USA-25/Presentations/US-25-Rao-Lost-and-Found-The-Hidden-Risks-Of-Account-Recovery-In-a-Passwordless-Future.pdf) are also rich with content and should be given a read over.  For instance, from the session termination perspective a major design flaw is that sessions are allowed to remain in-place after an account recovery action has been performed.  The slides give a fantastic diagram for this, as we can see below.

The team also gives a solid list of best practices that should be considered.  The team goes into far more detail through the slide deck (which, again, is fantastic) but their slide on the ideal recovery flow is particularly salient here.

Given the increasingly automated and human-detached processes that make up account recovery, we as practitioners need to understand the choices we are making as part of that process to extract the enterprise from assisting directly with account recovery.  This means we need to build trust from the start, communicate meaningfully with the user about account state, and ensure that recovery actions are meaningful through session termination and communication back to the user.

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

Author

Rusty Deaton has been in Identity and Access Management for over a decade. He began in technology as a technical support engineer for a Broker-Dealer and has since worked across many industries, carrying forward a passion for doing right by people. When not solving problems, he loves to tinker with electronics and read. He currently works as Federal Principal Architect for Radiant Logic.ghts on identity security through his blog at iam.ninja and engages with the IAM community on LinkedIn. When he’s not deep in security design, you’ll find him playing pickleball, writing about personal finance, stargazing, or playing tabletop board games.

The post The Threat of Recovery appeared first on IDPro.