The attacks arrive to find nothing to act on.
A questionnaire is a theory of where systems fail
Reviews of identity infrastructure are organized around three objects: a credential store to protect, a session to hijack, and, for biometric systems, a template database to govern. Most vendor answers describe the controls placed around those objects, which is a fair answer to the question as asked.
This paper answers differently. It walks the architecture object by object and shows which ones were designed out rather than defended, then states every remaining mechanism precisely enough that you can test it against a live tenant instead of believing it.
What the paper establishes
This is the longest and most technical paper in the series, and it is arranged as the questions a reviewer actually asks, in the order they arrive rather than in the order that flatters us.
Every answer is written to be falsifiable. Where a claim needs a limit, the limit sits in the same sentence as the claim, because a boundary you discover during the call is worth nothing.
- An artifact-by-artifact inventory of what a full database exfiltration yields, and why possession of each confers nothing
- Why there is no OP-side SSO session for end-user authentication, and the deliberate scope of that claim
- Token discipline: per-tenant issuers, the narrow authorization surface, and what happens when a spent refresh token is replayed
- The device protocol's five properties, from replay dedup to make-before-break key rotation
- How anti-enumeration is held as an invariant rather than a per-endpoint behavior, including the latency clause most systems fake
- Key custody in its two shapes, and the precise scope of the hash-chained audit trail
Who it is for
Security reviewers, penetration testers, and architects running a vendor assessment. Send your questionnaire as it stands: the paper is written to be read next to one, and the 30-day trial that lets you check the answers takes no card.
Note the limits as well. The administrative console keeps an ordinary browser session, so the no-session claim is scoped to end-user authentication. SenseCrypt also computes and emits roles and permissions in the token while your application enforces them, which means there is no per-access-decision audit log for us to hand you.
Frequently asked questions
Does SenseCrypt keep any session at all?
Only on the management plane. The administrative console keeps a browser session; there is no OP-side SSO session for end-user authentication, so every authorization runs a fresh face ceremony. The paper scopes that distinction carefully, because an unscoped version of the claim would be false.
Can we run our own questionnaire against a live system?
That is what the paper is written for. It names each mechanism so you can test it: sign in, inspect the tokens, replay a spent refresh token, probe an unknown identifier and time the response. Send the questionnaire as it stands.
How long is it?
Eight pages, the longest in the series, with three diagrams including the refresh-token family state machine.
Related reading
