Notifications
Clear all
Topic starter
22/06/2026 5:03 pm
TL;DR: Time-boxed, high-risk requests for actions like password resets, privilege elevation, or identity configuration changes can be made to require two or more humans to cryptographically approve them before execution, using a strict state machine and auditable quorum logic, according to Scramble ID. The security question is no longer whether an action can be approved, but whether the approval path is bound tightly enough to resist spoofing, social engineering, and single-operator compromise.
NHIMG editorial — based on content published by Scramble ID: Lockstep Dual Control Status (June 2026)
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Classify the highest-blast-radius identity actions first Start with password resets, factor resets, admin grants, SAML changes, and break-glass access.
- Bind approvals to the exact request object Require a scoped resource, immutable action verb, and hard expiry window for every request.
- 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.
What's in the full article
Scramble ID's full design note covers the operational detail this post intentionally leaves for the source:
- The canonical Lockstep state machine and request lifecycle, including how PENDING, PARTIAL, APPROVED, DENIED, and EXPIRED behave.
- Implementation details for idempotent request creation, signed callbacks, and streamable status updates.
- Approver UI requirements, including request context, origin, expiry countdown, and diff display.
- Concrete use cases for helpdesk resets, identity configuration changes, and break-glass access.
👉 Read Scramble ID's design note on Lockstep dual control for identity actions →
Lockstep dual control for identity actions: what changes for IAM teams?
Explore further
22/06/2026 5:18 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Lockstep dual control makes high-risk identity actions require quorum
