Built for your security review

A questionnaire arrives with its objects already chosen. Somewhere there is a store of credentials, somewhere a session that can be lifted, and, if the system uses faces, a database of templates that will outlive everyone in it. Vendors answer by listing the controls wrapped around those objects, which is responsive to the question as written.

The walkthrough takes those same objects in the same order and reports, for each one, whether it exists here at all. Where it does not, the paper says what stands in its place. Where it does, the mechanism is described in enough detail for a reviewer to run it against a live tenant rather than accept a description of it.

It is the longest paper in the series and the most technical. The sections follow the order in which reviewers actually raise things, which is not the order that would present the product most favorably.

Start with the retained-data inventory. IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Assess each artifact against its encryption and processing boundary, including the separate licensed on-premises service boundary.

The session next. End-user authentication keeps no OP-side SSO session, so each authorization runs a fresh ceremony rather than honoring a standing assertion that this browser belongs to that person. The scope of that statement is deliberate and the paper holds itself to it: the administrative console, like any operator dashboard, does keep a browser session, and the paper describes how that session is built instead of pretending it is absent.

Then the protocol surface, which is ordinary standards work done strictly. OAuth 2.0 with authorization code and PKCE is the only browser flow and S256 the only accepted transform. Confidential clients can keep authorization parameters off the front channel with pushed authorization requests under RFC 9126. Every tenant is its own issuer with its own keys, and refresh tokens rotate in families that revoke wholesale when a spent token reappears.

1. Each persisted artifact in turn, with what it is and what an attacker holding it can do next
2. The absence of an OP-side SSO session on the sign-in plane, and the management-plane exception the claim has to carry with it
3. How issuers, flows and refresh rotation are arranged, and what the system does the moment a spent refresh token comes back
4. Five properties of the protocol between the companion app and the platform, including how key rotation avoids leaving a gap
5. Why enumeration resistance is an architectural invariant here instead of an endpoint-by-endpoint promise, and the timing behavior that is hardest to deliver honestly
6. The two key custody models a tenant can choose between, and exactly which actions the hash-chained audit trail covers

Reviewers, penetration testers and architects part-way through a vendor assessment. The paper is meant to sit open next to a questionnaire, and the questionnaire does not need adapting first.

It is also written for the reviewer who has learned to distrust an architecture document that never says no. Several of the answers here are limits, and they are printed at the same size as the capabilities.

Eight pages, which makes it the longest of the seven, and three diagrams, one of them the state machine for refresh token families. It reads better beside a live tenant than beside a coffee, because most of it was written to be checked rather than absorbed.

The gated download sits on sensecrypt.com, and a copy of the PDF is available on request. What comes with it matters more than the document: a tenant to point the questionnaire at, and engineers who would rather argue about a result you produced than about a paragraph they wrote.