← Research
LuMiNx report

Passwordless by construction: a threat model for OrbitID

Authors
LuMiNx
Date
12 Apr 2026
Venue
LuMiNx Technical Report TR-2026-01

Abstract

We present the threat model behind OrbitID, an SSO provider that eliminates shared-secret authentication entirely. We enumerate the attacks that legacy providers leave open by retaining password fallback and email-link recovery, and show how a possession-and-presence model closes them while remaining compatible with OIDC relying parties.

Background

Most “passwordless” identity products of 2018–2025 retained passwords as recovery, fallback, or admin override. The result was a system whose attack surface remained equivalent to a password-based one even when the common path was passkeys. OrbitID treats this as a category error: any system in which a password could be accepted is a password system.

Threat model

We enumerate three adversaries:

  1. The remote credential adversary, who attempts authentication from anywhere on the public internet.
  2. The recovery adversary, who has compromised a user’s email or phone number and attempts to use the recovery channel as a side-entrance.
  3. The operator adversary, who has compromised LuMiNx infrastructure and attempts to issue authentication assertions on behalf of users.

For each, we describe the historical attack, our mitigation, and the residual risk after mitigation.

Mitigations

The first adversary is mitigated by the WebAuthn primitive itself: there is no shared secret to phish, and the assertion is bound to the relying party’s origin.

The second adversary is mitigated by replacing email-link recovery with attested device transfer or trusted-contact quorum. Email is, at most, a notification channel.

The third adversary is mitigated by requiring all authentication assertions to be signed by hardware-attested user keys, not by an operator-held signing key. The operator cannot forge an assertion the user did not produce.

Residual risk

We discuss the residual risk in §5 (loss of the last device combined with loss of the recovery quorum), and argue that this is the only class of failure a possession-based system can suffer — one which is qualitatively safer than the historical password-based failure modes.

Conclusion

A practical, OIDC-compatible identity provider can be built without accepting passwords anywhere in its surface, and doing so closes a category of attack rather than merely making it less likely.