Lockstep dual control makes high-risk identity actions require quorum

At a glance

What this is: This is a proposed dual-control model for high-risk identity actions that requires quorum approvals, cryptographic proof, and a hard expiry window before execution.

Why it matters: It matters because IAM, PAM, and helpdesk teams need approval controls that resist spoofing, social engineering, and single-operator compromise on irreversible actions.

Context

Lockstep is a dual-control pattern for identity operations that should not execute on the basis of one person’s approval. The model binds a specific request to a short-lived approval window and requires cryptographic confirmation from distinct approvers before the action can proceed.

For identity programmes, the governance question is not whether approvals exist, but whether they are tied to the exact high-risk request and protected against replay, spoofing, and account takeover. That makes the pattern relevant to helpdesk resets, privilege grants, identity configuration changes, and other actions with high blast radius.

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. 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: 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. Email sign-off only shows that someone clicked a link or replied, which is easy to spoof, replay, or misdirect. The difference is enforcement. One can prove quorum on the exact request, while the other mostly documents intent.

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. If a single approval could enable takeover, fraud, or widespread misconfiguration, the workflow belongs in a dual-control policy rather than a normal ticket queue.

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.

Technical breakdown

How quorum-bound identity approvals work

Lockstep uses a state machine to make approval status explicit: pending, partial, approved, denied, or expired. That matters because the request cannot silently drift from one state to another, and only the approved state authorises execution. Quorum is defined by distinct identities, not repeated clicks from the same person, and a single rejection can terminate the request. The design also requires a scoped resource, a bounded TTL, and cryptographic proofs from bound devices or keys, so the approval is tied to the request rather than to a generic inbox or chat thread.

Practical implication: model high-risk approval flows as auditable state transitions, not informal ticket comments or message-thread consent.

Why email and Slack approvals fail for privileged actions

Legacy approval channels are weak because they are usually detached from the exact request, easy to spoof, and rarely cryptographically bound to the approver. Email links and chat pings can confirm intent, but they do not prove that the approver saw the exact action, origin, and expiry window. In a dual-control design, the approval must be bound to the Lockstep session, the specific resource, and the requester context. That closes the gap between social approval and machine-enforced authorisation, which is where many high-risk identity workflows fail today.

Practical implication: replace loosely coupled human sign-off with request-bound, device-bound approvals for irreversible identity changes.

Where two-person integrity belongs in identity operations

Two-person integrity is most defensible when the blast radius is high and the action is hard to reverse. In identity operations, that includes password and factor resets, admin role grants, SAML key rotations, redirect URI edits, allowlist changes, and break-glass activation. The control is not meant for every workflow. Its purpose is to force deliberate friction only where a single compromised account or socially engineered agent could otherwise cause outsized damage. That makes scope discipline part of the design, not an implementation detail.

Practical implication: reserve dual control for the few workflows where one bad approval creates disproportionate loss or takeover risk.

NHI Mgmt Group 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.

Cryptographic approval binding is the important design change, not the presence of a second approver. A second human in the loop does not help if the request can be replayed, spoofed, or approved outside the exact context of the action. By tying approval to a specific LSID, TTL, and device-bound proof, the model narrows the gap between intent and execution. The named concept here is approval-path binding, which is what separates durable control from ritualised sign-off.

High-risk identity actions now deserve the same rigor as privileged infrastructure changes. The article correctly places identity configuration alongside financial approvals and destructive operations because the blast radius is often comparable. That matters for IAM, PAM, and helpdesk teams that still treat some identity changes as routine service work. The practitioner takeaway is to classify identity workflows by consequence, not by team ownership.

Dual control exposes where separation of duties is only theoretical. The design assumes approvers are distinct, independent, and able to block as well as approve, which is exactly what many real workflows do not guarantee. When the same team, shared mailbox, or informal rota can both request and approve, the control collapses into process theatre. Practitioners should use this model to find where SoD exists on paper but not in execution.

Lockstep-style controls will push identity programmes toward request-time enforcement. The model depends on a narrow approval window and a single terminal success state, which means governance has to happen before execution, not after the fact. That is consistent with modern identity control design, where the decisive question is whether the action was authorised under the right conditions at the point of use. Teams should expect more policy logic to move into the workflow itself.

What this signals

Approval-path binding: The real control is not “two approvals” but two approvals that are cryptographically bound to one request, one TTL, and one resource. That shifts governance from informal corroboration to machine-enforced accountability, which is the only version that holds up under spoofing or replay.

Identity teams should expect dual control to remain selective rather than universal. The model is best used where mistake cost is asymmetric, meaning the workflow should absorb a few extra seconds only when the failure mode is account takeover, destructive change, or irreversible fraud.

For practitioners

• 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.
• Set short approval windows Keep the TTL tight enough that a pending request cannot be captured later through account compromise or delayed social engineering.
• Audit denial and expiry outcomes Treat denied and expired requests as governance signals and review them for policy gaps, unclear scopes, or approver overload.

Key takeaways

• High-risk identity actions should be governed as dual-control events when a single approval could cause takeover, fraud, or catastrophic misconfiguration.
• The model’s protection comes from request-bound cryptographic approval, distinct approvers, and a short expiry window, not from extra human review in the abstract.
• For practitioners, the main decision is where to apply quorum controls so separation of duties is real on the workflow, not just documented in policy.

Key terms

• Dual Control: A governance pattern that requires two independent authorised people to approve a sensitive action before it is released. In finance, it reduces the chance that a single compromised identity can move money or alter payment instructions on its own.
• Quorum Approval: Quorum approval is the minimum number of distinct, eligible approvers required for a request to proceed. For identity workflows, it turns approval into an enforceable control condition, not a courtesy review, and it is only meaningful when identities, devices, and request context are bound to the decision.
• 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.
• Approval-Path Binding: Approval-path binding means the authorisation decision is cryptographically tied to the exact request, resource, and expiry window being approved. In practice, this prevents spoofed, replayed, or off-path approvals from being treated as valid for a high-risk identity action.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.