Revocable by Design

Design the exit before you design the onboarding. The test is simple: the customer can cut off your access unilaterally, and nothing on your side can delay or veto the cut. To pass it, put every trust anchor in the customer's account: the IAM role trust policies your control plane assumes through, the OIDC federation configuration that exchanges a workload identity for cloud credentials, the service-account bindings, and the onboarding stack (a CloudFormation-style template) that created all of them. Your control plane authenticates through those anchors with calls like STS AssumeRoleWithWebIdentity and holds no credential that survives them. When the customer deletes the onboarding stack, every credential the control plane could ever mint becomes invalid at the provider's IAM layer. The customer needs no ticket, no waiting period, and no goodwill from you.

Keep the division of labor strict. The control plane requests short-lived credentials at the moment of use, scopes each one to a task, and stores nothing that outlives the session. It never holds the trust anchors themselves and never keeps a fallback credential for emergencies. The customer account holds the durable objects: trust policies, federation configuration, KMS-owned keys, and the CloudTrail-class audit log that records both the grant and its revocation. Because the control plane owns no standing secret, deletion on the customer side is complete by definition; there is no vendor-side copy to chase.

Regulation gives this design a second mandate beyond security. Under GDPR, your customer is usually the data controller and you are a processor. Article 28 obligates the processor to stop processing and delete personal data when services end, and Article 17 lets data subjects demand erasure on their own schedule. In a conventional SaaS exit the customer has to take your deletion certificate on faith. In this architecture the customer can enforce both obligations unilaterally: revoking the trust anchors provably ends your processing at the cloud provider's IAM layer, the personal data never left an account the customer already controls, and their own audit log records the moment access ended. Deletion and termination become facts the customer can verify, which shortens security reviews and data-processing-agreement negotiations alike.

Make revocation granular along the seams the earlier commandments cut. The bootstrap grant used for initial setup expires when setup completes, and any runtime grant can be tightened without a redeploy (Commandment V). A single deployment cell offboards without touching its siblings (Commandment I). An operator session ends when its token expires (Commandment V). The blast radius of withdrawn trust should match the blast radius of compromise: the customer withdraws exactly as much trust as the situation demands, and no more.

Engineer cooperative offboarding as an idempotent workflow that your control plane drives. Every stage must converge on re-run, because a half-revoked state is harder to audit than either endpoint and can leave residual access that neither party is tracking.

Finally, verify that nothing orphaned survives. Because the architecture issues no static credentials (Commandment IV), there is no forgotten key that still works after offboarding. Once the trust policy is gone, the cloud provider's IAM evaluation denies every request from your control plane; enforcement sits with the provider and does not depend on your runbooks or your uptime. Publish the procedure, keep it short, and make sure a customer can execute it alone. A documented answer to "how do I cut you off right now" is part of the product.