01
The last users can delay the rollout
Ceremony-first rollouts all produce the same curve, and which credential is being rolled out barely changes it. The opening weeks belong to the people who were always going to enroll. Then it flattens, and what is left is everyone a reminder campaign was never going to reach: staff on extended leave, contractors, frontline workers without a corporate mailbox, shift workers sharing one terminal, senior people whose calendars swallow every prompt.
Completion therefore depends on decisions the program cannot make on anyone's behalf, so the finish date is a forecast rather than a commitment. That would be a scheduling annoyance if the tail were cosmetic, and it is not, because of what has to stay switched on while the tail is open.
None of this is a defect in any particular credential. It is the arithmetic of building coverage one person at a time, and some fraction of every population does not act.
Incomplete enrollment keeps passwords in use
While anyone still lacks the new factor, the old sign-in path stays available to everybody, because the system cannot know in advance who legitimately needs it. Attackers take that path rather than the new one, so the very exposure the program was funded to eliminate is still in place when the program closes.
Device changes repeat enrollment work
A credential that lives on a device has to be re-established whenever the device changes, so each replacement handset sends its owner back through the ceremony. The cost does not end with the project; it scales with the fleet.
Enrollment exceptions create impersonation risk
A rollout produces a steady stream of people who cannot sign in and need an exception, and a busy exception queue is exactly where a well-prepared caller sounds routine. The helpdesk paper in this series takes up what happens next.
02
What the paper covers
The order of operations is reversed. Coverage is produced first, by the organization, from material it already holds: the photograph taken at hiring, the KYC file captured at onboarding. Sealed tokens are minted from those images as a batch, so the population is covered before anyone has been asked to do anything, and retiring the legacy path becomes a date the organization picks.
That is the easy half and it takes the fewest pages. The rest goes to the machinery that decides whether a deployment still looks like this in year two: joiners provisioned over SCIM 2.0, movers whose appearance drifts across years, leavers whose access has to stop at a defined moment rather than whenever a token happens to expire.
The restraint that makes a bulk mint safe to run is stated plainly. An image exists only in memory: it is handed to an isolated minting service, a token comes back, and the image is released there. Nothing about it is committed to disk, to a database or to a log line at any stage. What the platform retains is a sealed token it cannot open, alongside a hash of the verifier sealed inside it.
- Three costs a ceremony-first rollout accumulates, one of which recurs for as long as the fleet exists
- What the batch mint does step by step, and where each photograph ends up
- Two routes for a population that arrives without a single image, neither of which puts a photograph in front of the platform
- How the directory stays the source of truth through joiners, movers and leavers instead of drifting apart from the deployment
- Why aging is handled by re-minting at each verified sign-in rather than by quietly adjusting a stored template
- Three capabilities that were deliberately not built, and the security property each absence buys
03
Who this paper is for
Program owners and IAM architects putting a number against a rollout, plus anybody who has taken a flat enrollment curve to a steering committee and been asked when the old path can close. The lifecycle material belongs as much in an operations review as a security one, because the running cost of the program is settled there.
The paper assumes there are images to start from. That assumption holds for most workforce deployments and fails for most customer-facing ones, which is why the alternative has a paper of its own rather than a footnote.
04
Assess your own enrollment rollout
Six pages, with a comparison of the two rollout shapes and an account lifecycle diagram. Read the lifecycle section with your own joiner, mover and leaver processes open beside it, since that is where a deployment either matches an operating model or quietly does not.
The gated download sits on sensecrypt.com, and a copy of the PDF is available on request. If you would rather test the claim than read it, the exercise worth running is a pilot import against a sample of the directory.
05
Frequently asked questions
What if we hold no photos at all?
Then this is the wrong paper and Trust on first use, proof ever after is the right one. The two no-photo routes are sketched here and worked through there: a directory can be imported in already-tokenized form, and self-signup users mint on their own handset, so in neither case does an image arrive at the platform.
What happens to the photos used for the batch mint?
An image is passed in memory to an isolated minting service and released the moment a token exists. It is never committed to disk, to a database, or to a log line. What survives the operation is a sealed token the platform has no code path to open, plus a hash of the verifier held inside it.
Does appearance change break the enrollment over time?
No, and the mechanism matters. Each successful sign-in retires the current token and mints a replacement sealed against the face as it is that day, so the credential follows the person through verified events. Where the organization replaces the photo on file instead, the new image has to be biometrically the same person as the enrolled user, or nothing is minted at all.
What happens when someone leaves?
Deprovisioning follows the directory. When SCIM 2.0 deactivates the record, the device keys and refresh token families bound to that account are severed, so access ends at a defined event rather than drifting until something expires on its own schedule. The paper is specific about the moment that binding takes effect, because that is the point an auditor will press on.