Why One OTP Cannot Cover Wi-Fi, VPN and a Registry

Single sign-on promises one identity and fewer prompts, and the promise breaks at the third protocol. The trap is assuming that one successful authentication produces a token every other protocol can present. Wi-Fi admission, VPN entry and a container registry each run a different exchange, with different audiences and lifetimes. Sharing the account is a directory decision; sharing the credential is a protocol decision, and the protocols rarely agree.

Three exchanges, three owners

Enterprise Wi-Fi runs an EAP method inside 802.1X, usually terminated by a RADIUS service that has its own view of the user or device. A VPN gateway authenticates through its own supported flow and then keeps a session with its own reauthentication timer. A registry answers an unauthenticated request with a challenge naming a token service, an audience and a scope, and the client exchanges its credential for a short-lived token.

Those are not three views of one session. Each has its own verifier, its own lifetime and its own revocation path, which is why a password change in the directory can leave one of them working and another broken. Treat them as three integrations that happen to share a user directory.

What browser SSO does and does not carry

A browser session at an identity provider is genuinely useful: applications that redirect to it inherit the login the user already completed. That works because those applications speak the same redirect and token protocols and accept the same audience. A supplicant that speaks EAP has no redirect to follow, and a Docker client that receives a registry challenge is not asking for an OIDC ID token. The identity provider can only vouch for protocols it was built to speak.

The failure is easy to see in the logs once you know where to look. The identity provider reports a successful login while the Wi-Fi association still fails, or the registry returns 401 after a token exchange the browser never saw. Two successes and one failure are not a contradiction; they are three separate authentications.

Where a certificate replaces a repeated code

For managed devices, certificate-based EAP removes the human step without removing identity: the device presents a certificate, the RADIUS service checks it against the issuing authority, and revocation happens at that authority rather than in a shared secret. The trade is lifecycle work, because certificates expire and must be renewed before they do.

Registries have an equivalent split. An interactive user can log in once and let a credential helper store the resulting token, while automation should use a narrowly scoped service credential or workload identity. Neither should be a human's one-time code copied into a pipeline. The helper stores a token for a specific registry audience, so it cannot be repointed at the VPN gateway by editing a config file.

docker login registry.example.com

Compare the maintenance cost, not the prompt count

A shared credential looks cheap because the work is invisible until it fails. Count instead what each option costs over a year: enrollment, renewal, revocation, the blast radius of a leak, and the number of systems touched when someone leaves. A certificate fleet costs more to build and less to operate at scale; a copied code costs nothing to start and everything to unwind.

Then choose per leg rather than globally. Wi-Fi can move to certificates, the VPN can keep its supported SSO with MFA, and the registry can use tokens with explicit scopes. Record the owner, audience, scope, expiry and revocation path for each, and the prompts fall where they should instead of everywhere at once. That record is also the answer when an auditor asks which systems still trust a password.