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.

Now try deprovisioning the 200 service accounts, API keys, container identities, and AI agents they created over the past years. Most of us can’t even find them all, let alone revoke them systematically.

For every human identity we manage today, there are 50+ machine identities acting autonomously. Many organizations struggle to even inventory them, let alone govern them. And that’s not a failure of competence, it’s a failure of tools that were built for a different era. These identities authenticate millions of times per day, hold privileged access to production systems, and when they’re no longer needed, they don’t resign. They just linger, credentials intact, waiting to be exploited.

This isn’t a future problem. It’s happening right now – at a scale that traditional identity and access management was never designed to handle.

The New Reality

Containers spin up and die in seconds. CI/CD pipelines authenticate to production databases without human intervention. AI agents make autonomous decisions about which APIs to call and what data to access. Microservices communicate through mutual TLS certificates that rotate every hour.

Each one of these actors needs identity, credentials, and permissions. Each one can be compromised. Each one should be governed.

But traditional IAM systems were built for people who go through onboarding, work for years, and eventually leave. They weren’t built for identities that are born from automation pipelines, live for minutes, and vanish before anyone notices. While we strive for modern, ephemeral identity models, the reality for many of us is a sprawling landscape of legacy API keys and hardcoded secrets that can’t be rotated overnight.

Human identities emerge from HR systems and follow predictable business events: hiring, role changes, departures. Machine identities emerge from code deployments and follow automation events: pipeline runs, scaling operations, terminations. Traditional governance operates in human time with quarterly reviews and monthly reconciliation. Machine identities operate in machine time, where entire lifecycles complete in minutes.

A Day in the Life of a Workload Identity

To understand why traditional governance fails for machine identities, let’s follow a single workload through its entire lifecycle.

8:00 AM : A developer deploys a new version of the payment processing service. Kubernetes receives the deployment manifest and begins orchestration.

8:00:30 : The cluster issues a service account token with a 30-minute lifespan. This token is cryptographically bound to the specific pod, namespace, and service account. It’s not a password. It’s a certificate that proves the workload’s identity.

8:01:00 : The payment processor container starts. It presents its certificate to the database, which validates the signature and establishes a mutual TLS connection. In an ideal implementation, there are no API keys stored in config files, no secrets passed through environment variables. The identity is embedded in the runtime itself. While many of us are still working to eliminate hardcoded credentials from legacy systems, this represents the direction we’re heading.

8:15:00 : The token automatically rotates. The workload doesn’t notice. The old certificate expires, a new one is issued, and connections seamlessly transition. This happens transparently, with no service interruption.

8:30:00 : Another rotation. This service will rotate credentials 48 times in a single day, far more frequently than any human would change their password.

8:45:00 : Traffic decreases. Kubernetes scales the deployment down. The pod receives a termination signal and begins graceful shutdown.

8:45:10 : The pod terminates. The certificate expires. The identity ceases to exist.

Total lifespan: 45 minutes.

Traditional IAM review cycle: 90 days.

By the time a human reviewer would look at this access, the identity has been created, used, rotated dozens of times, and deleted. And this story repeats thousands of times per day across modern cloud environments.

The Authentication Gap

Machine identities don’t authenticate the way humans do.

There are no passwords to remember or forget. No MFA prompts. No browser redirects to an identity provider. The entire concept of “logging in” doesn’t apply.

Instead, workloads use certificates and cryptographic attestation. They prove their identity through mutual TLS, where both sides of every connection verify each other before exchanging data. Federation is handled through cryptographic trust between certificate authorities, not user-facing protocols like SAML or OIDC.

When a container needs to access a database, it doesn’t send a username and password. It presents a certificate that was issued by a trusted authority, signed with keys that prove it’s running in the expected namespace, with the expected service account, in the expected cluster.

This is fundamentally different from human authentication. And it requires a fundamentally different approach to governance.

The Path Forward: Four Principles for Machine-Speed Governance

Here are four principles for machine-speed governance:

1. Assume Ephemerality

We need to shift our thinking from long-lived credentials to ephemeral ones. API keys that last for years represent security debt waiting to be exploited. The target state is credentials that expire in hours, not months, with certificate-based identity and automatic rotation built into the system.

When credentials are short-lived by default, compromise windows shrink dramatically. An attacker who steals a token has minutes to use it, not months. And when credentials rotate automatically, there’s no human process to fail or forget.

2. Automate Continuous Verification

If we’re relying on humans to provision, rotate, or revoke machine credentials at scale, we’re fighting a losing battle. The volume and velocity simply outpace what manual processes can handle.

Governance must be embedded directly into deployment pipelines. When a service is deployed, identity is provisioned automatically. When it’s scaled, credentials are issued on demand. When it’s terminated, access is revoked immediately. No tickets. No approval workflows. No waiting.

And authentication isn’t a login event anymore – it’s every API call, every database query, every service-to-service interaction. Traditional security says “authenticate once at the perimeter, then trust inside the network.” That model collapses when workloads are distributed across clouds, data centers, and edge locations. Modern identity requires continuous verification, where every request is independently validated against current policy. This is the foundation of Zero Trust: never trust, always verify.

This doesn’t mean humans aren’t involved. It means we shift from executing tasks to defining policies that govern automated systems.

3. Trace to Humans

Every machine identity must map back to a responsible person or team. This is about metadata ownership, not manual management.

When a container is compromised, someone needs to answer for it. When a service account is over-privileged, someone needs to justify why. This doesn’t mean humans approve every credential, it means every automated system that creates identities has a clear owner, and that owner is responsible for the policies that govern what those identities can do.

In practice, this means tracking which team owns each service, which cost center it belongs to, and who has authority to change its access policies. Governance without accountability is theater.

What This Looks Like in Practice

Modern machine identity management uses workload identity frameworks like SPIFFE to provide cryptographic identities for every service, issued automatically, rotated transparently, and scoped precisely.

Authorization moves from role-based access control to policy engines that evaluate context. Not just “does this service have database access” but “is this service running in the expected environment, from the expected namespace, with the expected signature, requesting access to data it’s authorized to see.”

Observability links every action back to an identity. When a database query runs, logs capture not just what happened, but which workload identity issued it, under what policy, with what context. This makes forensics possible and accountability real.

And reconciliation happens continuously. Instead of quarterly reviews where humans click “approve” on screens full of cryptic entitlements, automated systems compare what’s deployed in runtime environments against what’s recorded in identity systems, flagging drift immediately.

The Stakes

Breaches increasingly target machine identities because they’re easier than phishing humans. An exposed API key or leaked certificate provides direct access to production systems without triggering MFA prompts or alerting security teams trained to watch for suspicious user behavior.

Compliance frameworks are catching up. Regulators who once focused exclusively on human access now ask questions about service accounts, API credentials, and workload identities. Every identity, regardless of type, must be governed with the same rigor.

The organizations that solve this problem unlock safe, scalable automation. They can deploy faster, scale larger, and move with confidence because they know exactly what’s running, with what identity, under what authority.

The Question Isn’t Whether

Human identity management took decades to mature. We don’t have decades this time. The machines are already running.

The question for identity professionals isn’t whether to govern machine identities, we know the answer. It’s how quickly we can evolve our tools, processes, and mental models to match the reality we’re already operating in. Because the invisible majority isn’t waiting for our permission to grow. It’s already here, at machine speed, at cloud scale, with access to everything that matters.

The only choice is whether we govern it or get left behind.

About the Author:

Prithvi Poreddy is a Product Leader specializing in Identity Security, IAM, and AI-driven Governance. He works at the intersection of Identity, Risk, and Intelligent Automation, helping enterprises build secure and scalable identity foundations.

Prithvi has led IAM initiatives at organizations including Meta, Lime, Deloitte, and World Bank, building scalable access models and advising C-suite teams on identity modernization. He is an active contributor to the Cloud Security Alliance’s Identity Management working group and the MCP security group, where he focuses on AI agent security and authentication challenges.

His current focus is AI-driven identity governance, designing frameworks for autonomous agent identities, and aligning human and machine access models. He shares his thoughts 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 Machine Identity at Scale: Why Traditional IAM Can’t Keep Up appeared first on IDPro.

Access and NHIs

There are some interesting observations to be made about access control and NHIs. And missing these views leads to misunderstanding NHI Access Control and results in conflicting advice and practices. Access control and NHI’s have at least 2 different aspects: Access to the component and Access by the component. And these different views can be evaluated in this visualization:

Figure 1: Access to and access by an NHI

In this illustration, an actor logs in to a component interactively. The actor has an account and authorizations to match. Accounts and authorizations are dependent on the J-M-L-process and probably Role Based Access Control.

The component in turn, logs into a resource, probably using a resource account and authorizations. Since the login is automated, the secret to login with is probably configured in the component. In this pattern, the component could be an application that gives access to the actor, and the application will login to the resource (potentially a database server) with a service account. The component could also be a camera, or a device.

This simple pattern shows two views on access: Access to the component and access by the component.

Permissions

As we discussed before, NHIs, Non-human Identities, are managed in the change management process and these identities belong to components, such as servers, robots (and RPA’s), devices, services and what not. And these components have a purpose in life. They perform tasks. And to do so, they need to have the correct permissions. 

Relevant here is that from a governance perspective, we must have the possibility to validate what actions the component has performed. It must be traceable; it must be recognizable: this task or transaction has been performed by this component. This is in fact where the concept of NHI is born: the component needs an identity, it needs an account and it needs authorizations in order to perform the tasks.

Figure 2: NHI needs access

So, the NHI is an identifier to grant authorizations to and to enable logging, monitoring and traceability of transactions performed by the NHI in the resource.

Authorizations granted will be defined following the Least Privilege principle: grant at most the authorizations that are minimally required to perform a task. Nothing more, nothing less. And the permissions needed are given based on the functional requirements of the tasks to be performed. 

In creating the change and during development of any component that will need an NHI, all relevant stakeholders must be contacted to give their views on granting permissions to the NHI. If the NHI belongs to a camera, it needs the authorization to access the network (an IP address), and it needs the permissions to store video images on a server and perhaps it even needs the permissions to send a notification to facility management. And so, the stakeholders are facility management, network management, server management, security management and probably also a privacy officer. All stakeholders have to define the least privileged authorizations.

That’s the easy part of access control: the NHI needs access to the systems it connects to and it needs the authorizations to perform the tasks that it was implemented for.

Login to the NHI

But there’s a second viewpoint to NHIs: actors who need access to the NHI. In the camera example: who can use the pan and zoom functions of the camera?

An example of this type of access is a component like an RPA. The RPA has access to resources. The authorizations to the resource are custom authorizations, least privilege dependent on the purpose of the RPA. The second view is: who has access to the RPA. The RPA is developed and configured by an admin or operator who can either configure the code of the RPA or change the config files to comply with the functional requirements. Since the actions change the behavior of the RPA, special authorizations and logging and monitoring are required to manage access.

And here the picture becomes cloudy. There can be lots of stakeholders who need access.

First there is the operator, the actor who manages and configures the NHI. An NHI must be managed. There is a config. Either in a config file or in the database or even in the connector. And perhaps this operator must log in to the component. There may be an internal admin account in the component. Yes, we covered that: a server has an admin account, and the server has an identity. And the admin account will be found on the network. Just like the server will be found.

Let’s have a look at this same camera: it has an IP address and perhaps a DHCP-name and there must be one or more accounts that can be accessed. There is the admin-account and perhaps an operator account, potentially a read-only account and, speaking of cameras, a backdoor account to upload malware…

And there may be an on-board webserver, with again an NHI, an account and permissions. It never ends…

Anyway, there are accounts to log in to, to get access to the component, with a default factory (-reset) password for the admin account. Yes, these secrets live in the open.

Figure 3: DevOps and NHIs

APIs anyone?

And now to make the issue even bigger:

Some components not only offer login features, but they may also have APIs to give access to inner application functions. And this gives us a second access problem: who can access the APIs? What controls do we need to enforce to secure the endpoints? And this is where the concept of access control based on keys and tokens is needed. A second secrets management point

… A second secrets management point of view. I will not dive deeper into this concept of API access and whether we need API gateways, policy enforcement points and policy management points to manage fine grained dynamic access to the component. But we need a trusted facility to manage secrets and sessions.

Figure 4: NHIs and secrets

Access Control Conclusion

There you have it: Access by the component requires an NHI identity and account, for granting authorizations and for auditability purposes. But the NHI is accessed too. Login to the NHI and API access to the NHI require different controls. And both concepts cannot be mixed. The NHI needs resources, hence it needs an identity, and the NHI is a resource, hence we will have to restrict access.

This access perspective completes the NHI picture. Lifecycle defines how NHIs come into being and are governed; access defines how they interact within systems,  both as consumers and as resources themselves. The takeaway is simple yet often overlooked: NHI access must be designed and audited in two directions. Treating them as human users oversimplifies the problem; treating them as governed, purpose-built components restores clarity and control.

About the Author:

André Koot is principal IAM consultant at Dutch IAM consultancy and managed services company SonicBee (an IDPro partner). And member of the Advisory Board of IdNext.eu. He has over 30 years of infosec experience and over 20 years of experience as an IAM expert, acting as architect, auditor and program lead. For the last nine years he has taught a 4-day IAM training course. André contributes to the IDPro BoK as committee member, author, and reviewer.

The post Understanding Non-Human Identities (NHI) Part 3: Access Governance appeared first on IDPro.