Risk-based authentication and the triad of risk in IAM decisions

At a glance

What this is: This is a primer on risk-based authentication that explains access as a combination of authentication, authorization, and three risk inputs: device, application, and context.

Why it matters: It matters to IAM and NHI practitioners because the same risk logic increasingly applies to service accounts, AI agents, and other non-human identities that need scoped, adaptive access.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• Only 5.7% of organisations have full visibility into their service accounts.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Beyond Identity's blog on risk-based authentication and the triad of risk

Context

Risk-based authentication is a way of making access decisions using more than a yes or no check. The primary governance gap is that identity confidence, device trust, and request context often live in separate control planes, which leaves security teams to stitch together signals after the fact rather than enforce them at the point of access.

For IAM teams, the NHI connection is direct. Service accounts, tokens, workload identities, and AI agents also make access requests, but their trust signals are usually thinner than those available for humans. That is why access policy needs to account for the device or workload posture, the sensitivity of the target application, and the context of the request. This is a typical enterprise problem, not an edge case.

The article's framing aligns with broader adaptive authentication thinking, but practitioners should separate user-centric verification from NHI governance. Human authentication can use biometrics or device presence, while NHI controls depend more on entitlement scoping, credential hygiene, and runtime policy enforcement. The operational challenge is to keep those domains aligned without assuming they share the same signals.

Key questions

Q: How should security teams apply risk-based authentication to non-human identities?

A: They should treat non-human identities as machine actors that need scoped, time-bound access, not human users with extra checks. Risk-based authentication can help at the session boundary, but NHI governance still requires secret rotation, entitlement limits, workload attestation, and fast revocation when behaviour changes.

Q: What is the difference between adaptive authentication and Zero Standing Privilege?

A: Adaptive authentication decides whether to add friction or deny access based on risk at the moment of request. Zero Standing Privilege removes persistent access altogether and grants rights only when needed. One manages confidence, the other manages duration, so strong programmes use both together.

Q: Why do non-human identities complicate zero trust access decisions?

A: Zero trust assumes every request must be verified, but NHIs often authenticate through long-lived credentials, service tokens, and automation paths that do not produce human-style evidence. That means trust must be established through workload posture, short-lived entitlements, and continuous validation of the execution context.

Q: When should organisations require step-up verification for access?

A: They should require step-up verification when the request touches high-value systems, unusual contexts, or elevated privileges that would materially increase blast radius if abused. The goal is not to slow all access, but to reserve extra checks for the combinations that indicate higher compromise likelihood.

Technical breakdown

Authentication versus authorization in adaptive access decisions

Risk-based authentication works because access is not one control. Authentication answers who or what is requesting access. Authorization answers what that identity may do once it is authenticated. In practice, strong authentication does not remove the need for tight authorization, especially when the resource itself is high impact. The useful model is to score both the identity assurance and the blast radius of the requested action. For non-human identities, the same logic applies, but the evidence set changes: keys, certificates, workload posture, and token scope matter more than biometrics.

Practical implication: Treat authentication strength and authorization scope as separate controls, then review both whenever a workload, token, or agent is granted access.

The triad of risk: device, application, and context

The triad of risk is a useful shorthand for combining three different inputs into one access decision. Device risk covers whether the endpoint or workload environment looks trustworthy. Application risk reflects how damaging the target system would be if misused. Contextual risk captures whether the request fits expected behaviour, such as location, time, network, or usage pattern. The model is valuable because it prevents teams from over-indexing on a single signal. For NHI governance, that is a reminder that token validity alone is not enough if the workload, network path, or usage pattern looks abnormal.

Practical implication: Map each high-value access path to device, app, and context signals, then define which combinations should trigger step-up checks or denial.

Progressive verification and why it is not the same as zero standing privilege

Progressive verification adds stronger checks only when the risk score justifies them. Silent verification checks possession of the private key, presence verification checks that a person is actively using the device, and user verification adds biometrics. This is different from Zero Standing Privilege, which removes persistent access and provisions rights only when needed. The two ideas can complement each other, but they solve different problems. Progressive verification reduces access uncertainty; Zero Standing Privilege reduces the time access exists. For NHI and agentic systems, both matter, but they cannot be swapped.

Practical implication: Use step-up verification for risky sessions, but pair it with short-lived entitlements and revocation controls for high-risk identities.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Risk-based authentication is necessary, but it is not an NHI governance strategy. The article usefully describes how to raise assurance at the point of access, yet that is only one layer of control. Service accounts, API keys, certificates, and AI agents fail in different ways because they lack the human recovery patterns this model assumes. Practitioners should treat risk-based authentication as an input to broader identity governance, not as the governance model itself.

The real gap is trust signaling for non-human identities. Human access can rely on presence and biometric checks, but most NHIs authenticate through secrets, certificates, or delegated workloads that have no equivalent user signal. That creates an identity blast radius problem, where a single credential can authorize repeatable actions across systems. The practical conclusion is simple: scope, rotate, and continuously validate non-human access instead of trying to humanise it.

Adaptive access becomes weaker when the target is an autonomous agent. An AI agent can pass through a workflow with legitimate credentials and still behave outside the intended policy envelope if the access scope is too broad. That is why NHI governance has to cover action boundaries, not just login boundaries. Security teams should expect policy engines to move closer to runtime authorisation for agentic systems.

Contextual risk is becoming the bridge between IAM and runtime security. The article's triad shows why access decisions improve when the environment is evaluated alongside the identity. In NHI programs, that means tying identity policy to workload posture, orchestration state, and credential provenance. Teams that still separate these controls will keep finding the same access problem in different forms.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• For a broader view of where those leaks lead, see the 52 NHI Breaches Analysis for root-cause patterns and control failures.

What this signals

Identity assurance will keep shifting closer to the workload boundary. As more access decisions are made by software rather than people, the useful question becomes whether the request came from a trusted execution context, not whether a user completed a familiar login flow. That is why NHI governance needs controls for credential provenance, runtime posture, and action scope, not just authentication prompts.

With NHIs outnumbering human identities by 25x to 50x, the operational reality is that human-centric authentication models cannot carry the whole programme. Security teams should expect more policy logic to move into orchestration, CI/CD, and workload control planes as access decisions become increasingly machine-mediated.

Ephemeral credential trust debt: the longer temporary credentials, tokens, or certificates remain valid, the more their original assurance decays. Teams should watch for any control set that treats short-lived access as automatically safe, because the risk window often extends well beyond issuance if revocation and telemetry are weak.

For practitioners

• Define separate policies for human and non-human access Do not reuse human adaptive-auth rules for service accounts or AI agents. Map which identities can use presence checks, which require cryptographic attestation, and which must rely on short-lived credentials and explicit entitlement review.
• Score access based on application impact Classify applications by blast radius, then require stronger checks for systems that expose sensitive data, financial operations, or downstream administrative paths. Use the highest-risk paths to drive policy, not the average case.
• Tie contextual signals to workload provenance For machine access, compare the source workload, runtime environment, orchestration state, and credential origin before granting access. If the request path does not match expected workload provenance, step up or deny.
• Pair risk-based access with revocation discipline Make every elevated session temporary and auditable. Even when a request passes risk checks, keep rotation, expiry, and offboarding controls in place so the access window closes quickly if the identity is later abused.

Key takeaways

• Risk-based authentication improves access decisions, but it does not replace identity lifecycle controls for humans or machines.
• The main governance lesson for NHI teams is that context, scope, and revocation matter as much as initial authentication strength.
• Programmes that combine step-up verification with short-lived credentials and tight entitlement boundaries will reduce blast radius faster than policy checks alone.

Key terms

• Risk-Based Authentication: An access model that changes verification requirements based on the estimated risk of the request. It combines identity assurance, device posture, application sensitivity, and contextual signals to decide whether to allow, block, or step up verification before access is granted.
• Triad Of Risk: A simple framework for evaluating access through three lenses: device risk, application risk, and contextual risk. It helps security teams avoid overreliance on any single signal and make more balanced decisions about when access is safe enough to proceed.
• Adaptive Authentication: Authentication that adjusts its challenge level based on observed risk rather than using one fixed login experience for every request. It can reduce friction for low-risk access while demanding stronger proof when behaviour, device posture, or target sensitivity looks abnormal.
• Identity Blast Radius: The amount of damage that can occur if an identity is misused or compromised. For non-human identities, blast radius is often shaped by credential scope, token lifetime, downstream permissions, and how quickly access can be revoked or rotated.

Deepen your knowledge

Risk-based authentication, workload context, and non-human access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for service accounts, tokens, or AI agents, it is worth exploring.

This post draws on content published by Beyond Identity: What Is Risk-Based Authentication? Read the original.