Single-Credential Test

Segregation of duties is usually described in terms of roles: an initiator and an approver, enforced by the application. The test that matters is narrower and harder: can any single credential produce the outcome without the second party?

The answer is frequently uncomfortable, and it is the difference between a control that operates and a diagram that describes one.

Why it matters

The paths that defeat segregation are rarely the ones the control was designed against. A database administrator updating a row bypasses whatever the application enforces. A deployment pipeline can change the code that enforces the approval. Neither appears in a role matrix.

A control that can be bypassed by an ordinary operational credential is not a control against the insider or the attacker who obtains one — which is the threat model it exists for.

Implementation patterns

• Enforce at a boundary the database cannot bypass: a signing service, a hardware module with policy, or an external approval record the payment path must validate.
• Count the deployment pipeline. A pipeline with production write access is a path around every application control, and it needs its own segregation — a change to the enforcing code approved separately from the change that would benefit from it.
• Genuinely separate credentials, devices and people for multi-party approval. Approvals sharing an identity provider account are not segregated, since one compromise satisfies both.
• Just-in-time elevation with expiry, approval and a recorded justification, rather than standing break-glass access exercisable without a record.
• Thresholds on bulk operations, since mass action is the highest-damage capability available and should require confirmation above a proportion.
• Immutable audit exported outside the platform's own trust boundary, so detection does not depend on the system being investigated.

Industry example

Financial platforms such as Brex, Ramp and Marqeta have the sharpest version: any path to an unauthorised transfer is a direct loss. The mature position is to assume compromise and design so the compromise is bounded and detectable — and the ability to describe what an attacker with any single credential could and could not do is itself a product requirement, increasingly audited by enterprise customers.

Failure scenarios

• Enforcement only in application code, bypassed by database access.
• The deployment pipeline uncounted, providing a path around everything.
• Standing break-glass access, exercisable without approval or record.
• Approvals sharing an identity, satisfied by one compromise.
• Audit stored inside the platform, reachable by whoever is being audited.

Trade-offs

Enforcement outside the application adds a dependency to the payment path and a component to operate, and just-in-time elevation slows incident response at exactly the moment speed matters.

The mitigation is a fast, recorded elevation path rather than an absent one — since a slow one is bypassed under pressure and a bypassed control provides nothing. The friction should be proportional to the consequence, which means read access is standing and value-moving capability is not.

Interview question

"Walk me through every credential in your organisation that could result in money leaving, alone. Include the database, the pipeline and break-glass — and tell me which of them you can currently detect."