Lockstep dual control makes high-risk identity actions require quorum

At a glance

What this is: This is a design for dual-control approval of high-risk identity and operational actions, with cryptographic quorum, short-lived requests, and auditable state transitions.

Why it matters: It matters because IAM, PAM, and NHI teams often protect the action itself but not the approval boundary, which is where fraud, privilege abuse, and emergency access failures often begin.

👉 Read Scramble ID's design note on Lockstep dual control for identity actions

Context

Lockstep dual control is a separation-of-duties pattern for high-risk identity actions. The core idea is simple: no single person should be able to complete an irreversible or high-blast-radius action on their own, and the approval must be tied to the exact request rather than a loose workflow callback.

For IAM, PAM, and NHI programmes, this is about governing the decision point, not just the credential or session. Password resets, factor resets, privilege grants, SAML changes, and break-glass access all become safer when approval is cryptographically bound, time-boxed, and explicitly auditable.

The model is most relevant where a mistake or compromise has immediate downstream impact. That makes it a governance control for identity operations, not a generic workflow feature.

Key questions

Q: How should security teams implement dual control for high-risk identity actions?

A: Start with the few actions that can materially widen access or cause irreversible loss, such as password resets, factor resets, admin grants, and identity configuration changes. Bind each request to a specific resource and TTL, require distinct approvers, and make denial or expiry terminal so the process cannot be quietly reused.

Q: Why do email and chat-based approvals fail for separation of duties?

A: They fail because they are easy to spoof, hard to bind to the exact request, and often lack proof that the approver was the intended person on the intended device. Separation of duties only works when the approval is cryptographically linked to the action, the identity, and the expiry window.

Q: What breaks when a single approver can complete a sensitive identity action?

A: The control stops being separation of duties and becomes a single-point-of-failure workflow. That creates a direct path from one compromised account or one socially engineered employee to privilege escalation, trust relationship changes, or emergency access abuse.

Q: Who should be accountable when a dual-control request is approved or denied?

A: Accountability should sit with the policy owner, the approvers, and the IAM or PAM team that governs the workflow. The policy owner defines what is high risk, the approvers provide quorum, and the platform team ensures the request is cryptographically bound and fully auditable.

Technical breakdown

Cryptographic approval binding for high-risk requests

Lockstep replaces fragile approval channels such as email links, chat pings, and ticket comments with cryptographic proofs tied to a specific request. The request has a scoped resource, a fixed TTL, and a quorum policy, so approval is only valid for the exact action and window intended. Each approver is bound to a distinct identity and device, which makes replay, spoofing, and off-request approval materially harder. This matters because the security property comes from binding, not from the presence of a second human in the loop.

Practical implication: use approval mechanisms that bind the approver to the exact resource, action, and expiry window.

Quorum state machines and terminal denial

A dual-control workflow is only defensible if its lifecycle is deterministic. In the model described here, a request moves through PENDING, PARTIAL, APPROVED, DENIED, or EXPIRED states, and only APPROVED can trigger execution. A single rejection collapses the request to DENIED, and expiry is terminal as well. That matters because ambiguous approval logic creates operator confusion, audit gaps, and opportunities for approval drift. A clean state machine also helps investigators and auditors reconstruct exactly what happened without inferring intent from scattered logs.

Practical implication: define terminal states and non-recoverable denial rules before you allow the workflow to protect production actions.

Identity configuration changes need the same controls as production actions

SAML key rotations, redirect URI changes, allowlist edits, and admin role grants are identity-control changes with production-grade blast radius. Treating them as routine admin tasks underestimates how quickly one compromised account can widen access across the environment. Dual control forces a second, independent check on changes that can alter trust relationships rather than just user convenience. In practice, that is where many identity incidents become enterprise-wide incidents, because the identity plane itself becomes the attack surface.

Practical implication: classify identity configuration changes as high-risk infrastructure actions, not ordinary admin workflow.

Threat narrative

Attacker objective: The attacker wants a single compromised identity to authorize an irreversible action such as privilege escalation, identity takeover, payout redirection, or emergency access abuse.

1. Entry occurs when an attacker compromises or socially engineers a single account that can initiate a high-risk request, such as a password reset or identity configuration change.
2. Escalation is blocked if the request remains bound to a specific LSID, because a second independent approver must cryptographically validate the exact action within the TTL.
3. Impact is prevented or limited when the workflow enforces quorum, terminal denial, and auditable state transitions before any destructive or privilege-expanding action executes.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

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

NHI Mgmt Group analysis

Dual control is no longer just a fraud control, it is an identity-plane trust boundary. The article’s model shows that the approval step itself has become part of the protected attack surface, not merely the process around it. Cryptographic binding, scoped requests, and terminal state handling are what distinguish real separation of duties from a performative approval path. Practitioners should treat approval integrity as a first-class IAM and PAM control.

Identity configuration changes deserve production-grade governance because they rewrite trust relationships. SAML key rotation, redirect URI edits, allowlists, and admin grants are not cosmetic admin events. They determine who can authenticate, where tokens can be redirected, and which pathways remain open after compromise. The governance implication is clear: identity infrastructure changes can be the fastest route to environment-wide privilege expansion.

Lockstep is most valuable where a single operator should never be enough to complete the action. That includes password resets, factor resets, payout destination changes, and break-glass access. The control does not slow the environment for its own sake; it selectively raises the cost of abuse only at the highest-blast-radius points. Practitioners should reserve dual control for the few workflows where one mistake becomes a systemic incident.

Approval quality matters as much as approval count. A second approver who can be spoofed, routed through a weak channel, or recruited from the wrong reporting line does not meaningfully improve assurance. The model’s insistence on distinct identities, device-bound proof, and precise rosters reflects a broader governance lesson: quorum is only real when independence is operational, not organizationally assumed. Teams should validate approver independence, not just approver presence.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how often lifecycle controls lag behind access design.
• For the lifecycle angle, see Ultimate Guide to NHIs , Key Challenges and Risks for how over-privilege and unmanaged credentials compound each other.

What this signals

Dual control will become a practical pressure point for identity programmes that still treat approval workflows as low-risk admin plumbing. The more an environment relies on fast-moving identity changes, the more attractive it becomes to attackers who need only one weak approver path. Teams should expect scrutiny to shift from who can request the action to how the approval is proven and recorded. For the wider governance context, the NIST Cybersecurity Framework 2.0 remains a useful baseline for mapping this control into protect and respond.

Approver independence is the hidden weak spot in many SoD designs. If the same team, same device, or same operational chain can satisfy quorum repeatedly, the control is more procedural than resistant. The next maturity step is to examine whether independence is real in practice, especially for emergency access and identity infrastructure changes.

Identity configuration actions are starting to look like trust-anchor operations, not admin convenience tasks. That means the programme decision is no longer whether to add more tickets or more review steps, but whether the trust boundary itself deserves dual control. When identity trust changes, the blast radius is often broader than the action suggests.

For practitioners

• Classify the highest-blast-radius identity actions first Start with password resets, factor resets, admin grants, SAML changes, and break-glass access. If a wrong approval would widen access or alter trust, it belongs in the dual-control candidate set.
• Bind approvals to the exact request object Require a scoped resource, immutable action verb, and hard expiry window for every request. Reject approvals that are not cryptographically tied to the LSID and the specific change being authorized.
• Define approver independence in policy, not by assumption Exclude the requester from quorum, require distinct identities, and for the most sensitive actions consider different teams or reporting lines. Independence must be enforced by policy and checked in the workflow.
• Use terminal denial and expiry states Make DENIED and EXPIRED non-recoverable so a fresh request is required. This reduces ambiguity, limits replay, and keeps audit trails clean for later review.

Key takeaways

• Dual control protects the approval boundary, which is often the real target in identity abuse and social engineering.
• High-risk identity actions such as password resets, admin grants, and SAML changes have production-level blast radius and need production-level governance.
• Cryptographic binding, distinct approvers, and terminal denial states are the controls that make separation of duties enforceable rather than ceremonial.

Key terms

• Dual Control: Dual control is a governance pattern in which two or more independent approvers must authorize a sensitive action before it can execute. In identity security, it is used for high-blast-radius operations such as password resets, privilege grants, and identity configuration changes so that one compromised actor cannot complete the action alone.
• Two-Person Integrity: Two-person integrity is the stricter form of separation of duties where no single person can both request and complete a critical action. It is used when the consequence of a mistaken or malicious decision is severe enough that the approval path itself must be protected as part of the control.
• Quorum: Quorum is the minimum number of distinct, eligible approvers required to authorize a request. In dual-control identity workflows, quorum should be paired with distinct identities, device-bound proof, and terminal denial rules so that approval is both independent and non-replayable.
• Lockstep Session: A Lockstep Session is a time-boxed approval container for a specific request, scoped to a resource and a defined set of approvers. It exists only for the duration of the approval window, which keeps sensitive identity actions tightly bounded and auditable.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Scramble ID: Lockstep Dual Control Status (June 2026). Read the original.