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.
Editorial analysis by NHI Mgmt Group, based on content published by Scramble ID: “Lockstep: Cryptographic Dual Control for the Highest-Risk Actions”.
Key questions
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.
Q: Why do cryptographic approvals reduce risk more than email sign-off?
A: Cryptographic approvals reduce risk because they bind a specific approver, device, and request to the action being authorised.
Q: How should IAM teams decide which actions need two-person integrity?
A: Start with actions whose mistakes are hard to reverse or easy to weaponise, such as password resets, factor resets, admin role grants, SAML key rotations, and payout or allowlist changes.
Practitioner guidance
- Define a high-risk action list Classify identity operations by blast radius and start with the small set that can cause takeover, fraud, or widespread misconfiguration if approved once incorrectly.
- Bind approvals to the exact request Require the approver UI or workflow to show the requester, target resource, origin, expiry, and reason so the approval is tied to a specific change.
- Use distinct approver identities Enforce quorum from independent identities and prevent the requester from counting toward approval on the same session or case.
Bottom line: High-risk identity actions should be governed as dual-control events when a single approval could cause takeover, fraud, or catastrophic misconfiguration.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Dual control is becoming an identity governance control, not just an operational safeguard. The article’s model treats password resets, admin grants, and configuration changes as actions that require multi-party authorisation because one operator is no longer a safe trust boundary. That is a governance shift as much as a technical one, because the approval itself becomes part of the access control decision. Practitioners should read it as a policy boundary for irreversible identity events.
A question worth separating out:
Q: What should security teams do when a dual-control request is denied or expires?
A: Treat denied and expired requests as meaningful events, not dead ends. Review the reason, the approver set, and the request context to see whether the workflow is too broad, the TTL is unrealistic, or the approval roster is overloaded. Those outcomes often reveal where governance is brittle before an attacker does.
👉 Read our full editorial: Lockstep dual control makes high-risk identity actions require quorum