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 the browser session is not a credential: what it records, what every silent authorization re-checks, and the tenant setting that turns it off
- 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. SenseCrypt does keep a browser session on the sign-in plane, eight hours by default and set per tenant anywhere from zero (off) to thirty days; the paper explains why a captured one is not a credential rather than pretending it does not exist. 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?
Yes, two, and neither is a credential on its own. The administrative console keeps a browser session for operators. The sign-in plane keeps an OpenID Provider session after a face ceremony so an application can ask for a silent or a recent authentication; every authorization it answers re-checks the person's standing and the application's access rule, its lifetime is absolute and set per tenant, and a tenant can set it to zero so every authorization runs a fresh ceremony.
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
