Castle reference architectures/SaaS

Two person rule for root accounts

AWS root and DNS registrar accounts get approval gated MFA: any approver except the requestor can grant a scoped window, and every code display is logged for the auditors.

Approval thresholdPush notificationsNo self approvalAccess windowsAudit log
Infra engineers
Request + note
Approvers
Push notification · biometric
Request flow
CastleApproval based policy
Approval threshold1 OF N
Self approvalBLOCKED
Seed reconstructionIN ENCLAVE
Scoped code window1 HOUR
AWS rootDNS providerAny critical accountTier 0 accounts
Two person rule, enforcedClean trail for auditorsNo password manager bottleneck

Dataflow

01

The infra lead enrolls TOTP seeds for the AWS root account and the DNS provider, each under a critical infrastructure policy.

02

The policy names the requestor group, an approver group, an approval threshold, and a 1 hour access window.

03

A requestor asks for access with a short note (rotation needed for production keys). The request carries device details and geolocation.

04

Every approver gets a push notification showing the requestor, device, location, and note. Approval triggers a biometric check and response signing.

05

Castle blocks self approval structurally: the requestor’s own approval never counts toward the threshold.

06

On approval, the enclave generates a scoped window of codes encrypted to the requestor’s device. Every display is timestamped in the audit log.

Components

Approval policies

Requestor group, approver group, threshold, and window. The two person rule becomes configuration, not culture.

Push approval flow

Real time notifications with requestor context; one tap approve or deny, signed and verified by the backend.

Self approval block

Enforced by the access service, not convention. The requestor cannot satisfy their own threshold.

Access service

The stateless control plane: validates policy conditions, persists pending requests, coordinates the enclave.

Audit log

Requests, approvals, denials, and every code display, with actor, device, and time, exposed to the admin console.

Security considerations

The failure mode this kills: root 2FA locked in a password manager two people can access, both of whom might be offline or gone.

Auditors get what they actually ask for: who accessed the root account, when, approved by whom, from where.

Approvals are signed on device with a biometric step, so a compromised laptop cannot silently grant access.

The access window bounds exposure: codes exist for the approved hour and purge from the device after.

Deploy this architecture

Walk through the trust model, policy design, and rollout with our security and solutions team.

Learn moreAll architectures