TL;DR: C1.ai shows that passwordless onboarding still often begins with a temporary password or passcode, so the first credential remains a day-one exposure even when the end state is passkey-based authentication. The governance problem is whether joiner workflows can remove that interim secret entirely before enrollment.
At a glance
What this is: This is a blog post arguing that passwordless onboarding can still hide a first-day password or passcode, keeping the weakest credential in the joiner flow.
Why it matters: It matters because IAM teams can treat passwordless as solved while still exposing new hires to inbox-delivered bootstrap secrets, which weakens onboarding governance and day-one trust.
👉 Read C1.ai's analysis of passwordless onboarding and day-one password risk
Context
Passwordless onboarding is supposed to remove the first shared secret, but many joiner processes still use a temporary password or one-time passcode before a passkey is enrolled. That means the identity programme still depends on a bootstrap credential at the exact moment when the user has the least context and the weakest protection.
In this model, the security question is not whether passkeys work. It is whether the joiner workflow can move from HR provisioning to self-enrolled authentication without ever creating a reusable secret, even for a short interval. For modern IAM programmes, the gap sits in onboarding design rather than authentication technology.
Key questions
Q: What breaks when device onboarding still relies on passwords?
A: Password-based device onboarding creates shared secrets, slow revocation, and weak accountability. It also makes large fleets hard to audit because the secret, not the device lifecycle, becomes the control point. Standardised, revocable onboarding avoids that problem by tying trust to the device identity rather than to an embedded password.
Q: Why does a bootstrap credential still matter if the end state is passkeys?
A: Because the first credential is what establishes trust before the user can enrol a stronger factor. If that credential is weak, long-lived, or delivered through an exposed channel, the organisation has created a gap between account creation and secure authentication.
Q: What signs show that passwordless onboarding is not fully governed?
A: Watch for passwords or passcodes appearing in welcome emails, help desk scripts that read credentials aloud, long-lived bootstrap credentials, and manual handoffs between HR, IT, and the IdP. Those are signs that onboarding still depends on a secret that has not been lifecycle-managed as a control.
Q: How should IAM teams govern the first credential in a passwordless joiner flow?
A: Treat it as a tightly scoped enrolment token, not as a normal login secret. Limit who can issue it, keep the lifetime short, control the delivery path, and require passkey registration immediately after first use so the bootstrap secret cannot linger.
Technical breakdown
Why bootstrap credentials survive in passwordless onboarding
Passwordless authentication removes the need for a user to keep entering a memorised secret after enrolment, but it does not automatically solve the first login problem. Organisations still need a bootstrap mechanism so the new user can prove control long enough to register a passkey, an Authenticator app, or Windows Hello. That bootstrap can be a temporary access pass, a one-time code, or another short-lived credential. The technical issue is not the end-state factor, but the transition state between identity creation and first credential binding. If that handoff is not tightly governed, the rollout simply shifts risk from long-lived passwords to short-lived onboarding secrets.
Practical implication: model the onboarding transition as a separate trust event and control the bootstrap credential as tightly as any other NHI or human secret.
Temporary access passes versus persistent passwords
A temporary access pass is not a password in the usual sense because it is time-bounded, limited in use, and intended only to unlock initial enrolment. That makes it closer to a controlled bootstrap token than to a reusable login secret. The distinction matters because the attack surface changes: a persistent password can be reused, guessed, phished, or leaked for long periods, while a temporary pass mainly creates exposure during delivery and the validity window. The remaining risk is operational. If the pass is sent insecurely, stored in an inbox, or valid too long, the organisation has still created a day-one secret path even if the final authentication method is passwordless.
Practical implication: enforce short validity, one-time use where possible, and delivery paths that do not widen the bootstrap secret's exposure window.
Joiner workflow design, identity proofing, and first-factor trust
Onboarding design matters because the first credential is only as strong as the workflow that issues and delivers it. The article's pattern relies on HR as the trigger, the identity platform as the issuer, and email as the delivery path. Each step introduces a governance decision: who can trigger issuance, where the bootstrap secret is sent, and what proof is required before passkey enrolment completes. The problem is not just phishing risk. It is that the organisation may be treating identity proofing and first-factor issuance as a routine automation step when they are actually the point at which account trust is established.
Practical implication: treat onboarding issuance and identity proofing as a single control point instead of separate admin tasks.
NHI Mgmt Group analysis
Day-one credential exposure is a governance failure, not just an implementation detail: passwordless programmes still break down when the joiner workflow creates a temporary secret to bridge the gap to passkey enrolment. That secret is often the first and weakest credential the user ever receives, which means the identity programme has not actually removed password risk at the point where trust is being established. The implication is that onboarding design, not just authentication policy, determines whether passwordless is real.
Bootstrap secrets create a distinct trust boundary: a temporary access pass, passcode, or setup code should be treated as a controlled enrolment token rather than a convenience credential. If teams blur that distinction, they will overestimate the security of passwordless adoption and under-protect the delivery path. The field needs to separate account creation from initial credential binding with much more precision.
The named concept here is day-one credential risk: that is the gap between account provisioning and self-enrolled authentication, where a bootstrap secret still exists even though the target state is passwordless. This is where inbox delivery, help desk handling, and timing assumptions matter most. Practitioners should treat the first credential as an identity-control boundary, not an onboarding courtesy.
Joiner automation exposes whether IAM programmes actually govern transitions: the article shows that lifecycle workflows can automate both identity creation and bootstrap secret delivery, but automation alone does not make the process secure. The real test is whether the organisation can move from HR event to enrolled passkey without introducing an intermediate secret that outlives its purpose. That is a lifecycle governance problem, not a passkey problem.
Passkey adoption changes the attack surface, but only after the first factor is eliminated: passwordless authentication reduces reuse, phishing, and reset burden once it is established. Before that point, the organisation still has to govern delivery, expiry, and enrolment timing for the bootstrap method. The practitioner conclusion is simple: passwordless maturity is measured by whether there is any reusable secret left in the onboarding path.
From our research library:
- eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.
What this signals
Day-one credential risk: passwordless adoption does not eliminate trust establishment, it relocates it into the joiner workflow. That means lifecycle governance now has to cover bootstrap issuance, delivery, and expiry with the same seriousness as password policy once received.
For IAM teams, the practical test is simple: if a new hire can still receive a secret in email before enrolling a passkey, the programme is not yet passwordless at the point that matters. The control boundary has shifted to onboarding orchestration, identity proofing, and first-use enforcement.
For practitioners
- Map the joiner secret lifecycle Document every step from HR event to first passkey enrolment and identify where a temporary password, passcode, or access pass is created, delivered, stored, and revoked.
- Shorten bootstrap validity windows Set the temporary credential lifetime as tightly as the onboarding schedule allows and prefer one-time use where the business process can support it.
- Remove inbox delivery where possible Replace plaintext delivery to email with a lower-exposure handoff path or verified out-of-band channel so the bootstrap secret is not sitting in a mailbox before first use.
- Treat first-factor enrollment as a control point Require explicit governance for who may issue the bootstrap credential and what proof is needed before the passkey registration step completes.
- Audit onboarding for leftover passwords Review recent joiner workflows to confirm they do not still create hidden first-day passwords under the label of passwordless onboarding.
Key takeaways
- The post shows that passwordless onboarding can still start with a temporary secret, which leaves a first-day exposure window even when the target state is passkey-based authentication.
- The key operational issue is not passkey technology itself but whether joiner workflows can remove the bootstrap credential before it becomes a usable attack path.
- The strongest control is to govern the first credential as a short-lived enrolment token and eliminate plaintext delivery wherever possible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on bootstrap authentication during onboarding, where the first credential still creates a trust boundary. |
| NHI-07 — Long-Lived Secrets | The risk comes from temporary credentials that live long enough to be delivered, stored, or misused. | |
| NHI-10 — Human Use of NHI | The article shows humans receiving and handling a non-human bootstrap secret during onboarding. | |
| Recommendation — Use NHI-04 to review whether onboarding secrets are still acting as weak first-factor authentication. Apply NHI-07 to reduce the lifetime of bootstrap credentials before passkey enrolment completes. Use NHI-10 to prevent people from handling bootstrap secrets as if they were routine login passwords. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle management directly maps to issuing, expiring, and revoking the temporary passcode. |
| Recommendation — Apply IA-5 to govern issuance, validity, and revocation of onboarding authenticators. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The onboarding flow is about who gets access and under what conditions before passkey enrolment. |
| Recommendation — Use PR.AA-05 to ensure bootstrap access is limited to the minimum necessary enrolment path. | ||
| NIST Zero Trust (SP 800-207) | 5.1 — Identity Governance | The article is fundamentally about controlling trust during identity creation and first access. |
| Recommendation — Apply identity governance controls so first access is explicitly bounded and continuously verified. | ||
Key terms
- Bootstrap Credential: A bootstrap credential is a temporary secret used to get a new identity into its first trusted session when normal access paths are not yet ready. In identity governance, it should be time-bound, single-use, and auditable so it does not become a permanent side channel.
- Passkey Enrolment Fraud: Passkey enrolment fraud happens when an attacker gains temporary access to an account and registers their own device or authenticator as trusted. After enrolment, the attacker can authenticate legitimately because the system believes the new binding is valid. The weakness is not the passkey itself, but the governance around who can bind it.
- Day-One Credential Risk: Day-one credential risk is the exposure created when a new account still receives a temporary secret during onboarding. The risk is not the permanent authentication state but the brief window where the bootstrap secret can be intercepted, reused, or mishandled.
- Joiner, Mover, Leaver Workflow: A joiner, mover, leaver workflow is the process that grants, updates, and removes access as a user or identity changes state. In modern programs, the same logic should extend beyond employees to service accounts and AI agents so access does not persist after need ends.
What's in the full article
C1.ai's full blog covers the operational detail this post intentionally leaves for the source:
- The step-by-step joiner workflow that issues a temporary access pass and hands it to the new user
- The Entra ID and Graph API sequence used to create and expire the bootstrap credential
- The email delivery pattern for sending the first-use credential to the user or manager
- The article's sample automation path from HRIS event to passkey enrolment
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 4, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org