01
Every identity system starts with enrollment
SSH put the pattern on record decades ago, and RFC 4251 is candid about the trade it involves: a client meeting a host for the first time can accept a key it has no way to check, after which any change to that key is an alarm. The web makes the same move constantly and with far less ceremony. Control of a mailbox is demonstrated for one instant by clicking a link, and an account is created on the strength of that instant. Most signup funnels in production work exactly this way, whether or not the design document ever says so.
Which makes it useless to separate systems by whether they take the leap, since all of them do. Two other questions do the separating. What has to be produced before the leap, and how long the opening stays available. And then the one that is hardly ever asked: what the leap leaves behind once it has been taken.
A password bootstrap does poorly on both counts, and the second is the one that compounds. What is left behind is a secret that can be phished, bought or reset, together with a recovery route that reconstructs the original leap on demand for as long as the account exists.
Examine enrollment as well as sign-in
Bootstrap designs are usually judged on how hard the first door is to open. The residue decides more, because the residue is what every later attack acts on and what every recovery flow has to reproduce.
Passwords remain reusable after enrollment
Each reset re-runs the original mailbox proof, so the window is not one moment wide at all. It reopens for anyone who reaches the recovery flow with a plausible enough account of themselves.
Continuity protects the enrollment decision
SSH is tolerable because everything after the first connection is cryptographically continuous. A bootstrap is only as good as the proof chain that follows it, which is the standard this paper holds itself to.
02
What the paper examines
The subject is the deployment that starts from nothing: no HR photograph, no KYC file, no image of any kind to mint from. Two entrances lead into a single enrollment ceremony, and the interesting engineering sits in the entrances, so that is where the pages go.
The workforce entrance is a shell provisioned over SCIM 2.0 before the person does anything at all, carrying group memberships and entitlements but holding no token. Provenance is its anchor: the account exists because the directory said it should, and a stranger has no way to conjure one. The customer and B2B entrance is self-signup, and it stays off unless an application deliberately turns it on. New accounts land in a group whose access the organization has already bounded, and admission can be held to a list of approved email domains.
Then comes the section most bootstrap designs never write. Surviving the first use is only half of it. The first use also manufactures an account, and everything that account can do later is settled by how it was assembled.
- The two questions that separate one bootstrap design from another, and the poor answer a password program gives to each
- What authorizes admission through each of the two doors, and why one of them cannot be conjured by a stranger
- Where the email-domain allow-list is evaluated, and why a probe against it learns nothing about its contents
- Everything the enrollment code has to do: how it is stored, how often it may be tried, how long it lives, and how many can be outstanding at once
- Three bootstraps side by side, judged on their residue and on who can use the account a year later
- The first-use hijack taken seriously: what the attacker ends up holding, and why it is a poor prize
03
Who this paper is for
B2B SaaS platforms, CIAM teams, and workforce programs staring at an empty photo directory. Biometrics on day one is the companion piece for organizations that do hold images, and between them the two describe one lifecycle with two entrances rather than two products.
It is also the paper for a reader who wants to follow what happens to the account economics. A credential that is a string can be lent to a colleague, sold to a broker, or surrendered under pressure. An account bound to a live person cannot be passed around, and the paper traces that difference through recovery, replacement devices and dispute investigations.
04
Evaluate the enrollment flow yourself
Seven pages, two diagrams, and a comparison of what three bootstraps leave behind. The section on the enrollment code is short and worth a second reading if your own signup flow is under review.
The gated download sits on sensecrypt.com, and a copy of the PDF is available on request. The fastest way to judge the gates is to operate them: create a shell, enroll through it, then probe the perimeter with an address that should not be admitted and compare what comes back.
05
Frequently asked questions
Do we need photos on file to deploy SenseCrypt?
No. A great many customer-facing deployments, and plenty of workforce ones, begin with no images whatsoever. Those users come in either through a shell provisioned from the directory or through a signup gated on approved domains, and the face token is minted during the first ceremony on the phone already in their pocket, so no reference image reaches the platform by either route.
Is self-signup an open door?
It stays closed until an application switches it on. From there, a new account drops into a group whose access the organization has already bounded, and admission can be confined to a list of approved domains. The same check runs at every entry point, and an address that fails it receives the identical response, at the identical latency, as any other rejected attempt.
What does an attacker actually win by enrolling first?
An account permanently bound to their own live face. It cannot be resold, because there is no credential to hand over, and it cannot be shared with a crew, because every use presents the same face to a liveness check. Each verification lands in the person-level activity stream, and once the legitimate person reports the failure, deprovisioning severs the device keys and refresh token families. The face does not make first-use hijack impossible. It makes the prize small and the evidence trail personal.
Can the window be tightened for privileged accounts?
Yes, by moving those accounts onto the photo-on-file path instead. An organization that already runs a document check or an in-person identity process can verify a single photograph through it and mint the token from that image, which replaces the leap of faith with evidence the organization collected itself. The paper sets out the trade: a slower onboarding step, in exchange for a first use that no longer rests on one ceremony.