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.

Application onboarding still takes weeks or months in many enterprises. It relies on custom scripts and depends heavily on a small number of specialists. Over time, this creates inconsistent access controls, growing technical debt, and real difficulty responding to audits or regulatory changes. If any of this sounds familiar, you are not alone.

What Is Low-Code by Design?

Low-Code by Design is an approach where common IGA problems are solved once, rigorously tested, and then reused across many integrations. Rather than building every integration from scratch, reusable automation components handle recurring tasks: connector configuration, identity correlation, entitlement setup, provisioning rules, and certification configuration. Engineers still own the code and retain full accountability. However, they stop repeating the same mundane work for every new application.

The complexity of new development transforms into a centralized and standardized module which is tested in one place rather than scattered across dozens of bespoke implementations.

The Role of Metadata

For Low-Code by Design to work in practice, each reusable integration module must maintain rich metadata about the target application. This is the layer that allows a generic, reusable component to behave correctly across diverse systems without custom code.

One critical metadata attribute is the application’s account model: whether it supports single-account or multi-account identities. A human resources system typically maps one account per person, while a database platform or a privileged access environment might assign multiple accounts to a single identity, each with different entitlements and risk profiles. The integration module needs to know this up front so it can correctly aggregate accounts, run certifications against the right scope, and avoid creating orphaned or duplicate records during provisioning.

Equally important is the correlation logic: the rules that tie an account in a target system back to a known identity in the IGA platform. Different applications use different identifiers. Some correlate on employee number, others on an Active Directory sAMAccountName or UPN, and still others on email address or a proprietary user ID. The integration module must capture which correlation attribute applies for each target system and how to handle edge cases such as contractors without employee numbers or service accounts that do not map to any human identity. Without this metadata, every integration devolves into custom scripting to answer the same fundamental question: whose account is this?

When this metadata is captured as structured configuration rather than embedded in code, it becomes inspectable, auditable, and portable. New integrations inherit proven patterns and only need to specify the parameters that make their target system unique.

Low Code Framework

The framework abstracts the complexity of Integration to provide standardized interfaces to development teams and consists of the following core components

1. Inventory Management – This module is responsible for keeping track of integration lifecycle. Some categories include New, Invest Status, Decommission Status etc.
2. Integration Management – This module consists of an interface which provides the option to create a new integration or manage an existing integration by adding or removing features such as password management or group management.
3. CI/CD – This module promotes integration code from a lower environment to the UAT or Production environment. It also helps in securing custom code from inadvertent edits by dev teams.

Most organizations find it practical to begin with high-volume, repeatable use cases: file-based application onboarding, directory and group management, or standard access certifications. Early automation should cover the full identity lifecycle, from connector setup through provisioning and certification, and clearly document the decisions built into each component. This preserves institutional knowledge even as team members change roles.

As confidence and organizational maturity grow, the same approach extends naturally to more complex domains: hybrid cloud identity management, legacy platform integration, or cross-system entitlement correlation.

A Practical Example: File-Based Integrations

File-based integrations remain common across the industry, especially for legacy platforms and third-party systems that lack modern APIs. Traditionally, each file integration requires its own custom parsing logic, transformation rules, aggregation jobs, and provisioning scripts.

With a Low-Code by Design approach, teams build a reusable file integration module that includes standard templates, tested transformations, and predefined lifecycle workflows. Once that module is created and validated, it can be applied across many integrations with only minor configuration changes. What previously required weeks of custom development becomes a matter of days or even hours of configuration.

Traditional IGA and Integration Sprawl

For large organizations in particular, the deeper problem is integration sprawl. When hundreds of applications are onboarded independently over the years by different teams, the result is a fragmented landscape of connectors, inconsistent provisioning logic, undocumented transformation rules, and scripts that only their original authors understand. Integration sprawl does not just slow delivery; it creates hidden compliance risk, because no single person or team has a reliable picture of how access is actually being governed across the enterprise.

Low-Code by Design directly addresses integration sprawl by replacing this patchwork with a governed set of reusable modules, shared patterns, and centralized configuration. When every integration follows a common framework, organizations gain a single, auditable view of how applications are connected, what provisioning logic applies, and where exceptions exist. New integrations inherit proven patterns rather than inventing their own, and existing integrations can be rationalized onto the standard framework over time. The result is not just faster delivery but a structurally manageable integration estate that scales with the organization rather than against it.

Measuring the Success – KPIs

Traditional IGA metrics—certification completion rates, time-to-revoke, policy violation counts—still matter. But Low-Code by Design introduces additional indicators that reveal whether identity governance is becoming structurally easier to scale: time required to onboard a new application, cost per integration, reduction in custom scripts maintained, and the ability for more junior engineers to deliver reliable integrations independently. When these numbers trend in the right direction, the program is working.

Conclusion

• Low-Code by Design is a development methodology. It means solving common IGA problems once and reusing tested components across integrations.
• Integration metadata—account models, correlation attributes, application classification—is the foundation that makes reusable modules work across diverse target systems.
• Traditional per-application IGA onboarding struggles to scale. The math of limited team capacity against growing application portfolios demands change in development strategy and low code is the perfect answer.
• For large organizations, integration sprawl is the hidden risk. A common framework replaces fragmented one-off connectors with a governed, auditable integration estate.
• Start with high-volume, repeatable use cases. Cover the full lifecycle and document decisions to preserve institutional knowledge.
• Embed compliance from the start. Certification, separation of duties, and audit logging should be part of the automation, not an afterthought.
• This approach elevates, not diminishes, senior engineering expertise by shifting it from repetitive delivery into reusable design.

As identity environments grow more complex, traditional IGA implementation models will continue to strain under the weight of custom, one-off integrations. Low-Code by Design offers identity professionals a practical path to modernize—improving speed, consistency, and compliance without sacrificing engineering control. It is not a shortcut. It is a smarter way to build and scale identity governance.

Mr. Anant Wairagade is an internationally recognized Senior Cybersecurity Engineer and independent researcher with a Bachelor of Engineering in Computer Science. His expertise lies in a niche and highly visible field within the software industry: enterprise-scale identity and access management, with a particular emphasis on cloud security, zero-trust architectures, and the application of artificial intelligence. His significant contributions to this field, demonstrated through his publications, technical program committee work, and impactful achievements at American Express and other major corporations, have earned him a reputation as an expert in a specialized area.

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.n security design, you’ll find him playing pickleball, writing about personal finance, stargazing, or playing tabletop board games.

The post Low-Code by Design: A Practical Way to Modernize Identity Governance appeared first on IDPro.