up:: Security Basics MOC

Authentication

Authentication is the process of verifying that a user, process, or device really is who or what it claims to be, and it’s the gate that has to close before any access decision is made. It answers one question, “are you actually who you say you are?”, and it is separate from keeping data secret, from proving data wasn’t changed, and from authorization, which decides what a known party is allowed to do. Cryptographic authentication is delivered by digital signatures, certificates, and the public-key infrastructure that makes them trustworthy at internet scale, and every one of those classical building blocks rests on math that a large quantum computer running Shor’s algorithm can break, which is why proving identity is one of the two security goals the post-quantum transition exists to rescue.

The short version:

1. Authentication verifies identity, and answers “are you really who you claim to be?” It always comes before access is granted.
2. It’s distinct from authorization. Authentication establishes who you are; authorization decides what you’re allowed to do once you’re known.
3. It classically rests on three factors, something you know (a password), something you have (a key or phone), and something you are (a fingerprint or face), often combined as multi-factor authentication.
4. At internet scale, cryptography does the proving: a TLS certificate is a signed statement that authenticates a server, and the whole PKI is a tree of signatures vouching for identities.
5. The quantum threat attacks that certificate layer directly. Once Shor’s algorithm can recover a private key from its public key, an attacker forges signatures, mints fake certificates, and impersonates trusted services, and a forged root key means every certificate under it becomes untrustworthy at once.

Think about a sentry at a gate who recognizes a signet-ring seal. Someone rides up claiming to carry orders from the general, and the sentry checks the seal against the crest they know. If it matches, the rider is authenticated, the sentry believes the rider carries the general’s authority. Authorization is the next question entirely, whether those orders let the rider open the armory or only cross the courtyard. The danger is that the seal proves control of the ring, and says nothing about whether the rider stole it. A digital certificate is that seal at planetary scale, and Shor’s algorithm is a machine that carves a perfect copy of the ring from the public crest alone, so a forger can seal orders that pass every sentry.

What is authentication?

Authentication is verifying a claimed identity before trust is extended. NIST defines it as verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources. The claim comes first (“I am this user,” “I am this server,” “I am this device”), and authentication is the evidence that backs the claim. Until it succeeds, a system has an unverified assertion, not a known party.

Classically, that evidence comes from one or more of three authentication factors:

1. Something you know, like a password, a PIN, or the answer to a challenge.
2. Something you have, like a hardware security key, a smart card, or a phone running an authenticator app.
3. Something you are, a biometric such as a fingerprint, face, or iris.

Combining factors from different categories is multi-factor authentication (MFA), and it’s stronger because an attacker has to defeat two independent kinds of evidence at once, so a stolen password alone won’t get someone in when a hardware key is also required. NIST’s digital-identity guidance organizes this into authenticator strength and assurance levels, because “authenticated” is a spectrum, a reused password and a phishing-resistant hardware key both authenticate, at very different levels of confidence.

Source: NIST, “Security and Privacy Controls for Information Systems and Organizations,” SP 800-53 Rev. 5, September 2020, SP 800-53 Rev. 5.

Source: NIST, “Digital Identity Guidelines,” SP 800-63-3, June 2017, SP 800-63-3.

How is authentication different from authorization?

Authentication and authorization are two separate steps that people constantly blur, and keeping them straight is foundational. Authentication establishes who you are; authorization decides what you’re allowed to do once your identity is known. Authentication always runs first, because you can’t apply a permission rule to a party you haven’t yet identified. A system can authenticate you perfectly and then correctly refuse the action you asked for, a valid login followed by “you don’t have access to that.”

The two answer different questions, fail in different ways, and use different machinery:

Dimension	Authentication (authN)	Authorization (authZ)
Question it answers	Are you really who you claim to be?	What are you allowed to do?
When it runs	First, at the gate	After identity is established
Typical mechanism	Passwords, MFA, certificates, signatures	Access-control policy, roles, permissions
A failure looks like	Impersonation, spoofing, a forged identity	Privilege escalation, over-broad access
Cryptography’s role	Central, signatures and PKI prove identity	Supporting, crypto enforces the decision but policy makes it

The reason this matters for the quantum transition is that the cryptography under threat sits squarely in the authentication column. Authorization is largely a policy problem, so a quantum computer doesn’t break it directly. Authentication is a cryptography problem at internet scale, so it’s on the front line.

Source: NIST, “Security and Privacy Controls for Information Systems and Organizations,” SP 800-53 Rev. 5, September 2020, SP 800-53 Rev. 5.

How does cryptography provide authentication?

At human scale you authenticate with a password, but that model breaks down the moment two strangers who share no secret need to trust each other, which is the situation every time your browser connects to a bank it has never talked to before. Cryptography solves the stranger problem, and it does it with three related mechanisms:

1. Digital signatures. A digital signature proves a message came from the holder of a specific private key and wasn’t altered. Because only that key holder can produce a valid signature, a signature authenticates the sender to anyone holding the matching public key. This is the primitive underneath almost all cryptographic authentication.
2. Certificates and PKI. A signature only proves control of a key, so something has to vouch that the key belongs to the right identity. A certificate does that: it’s a signed statement binding a public key to a name (a domain, a person, a device), issued by a Certificate Authority the verifier already trusts. The public-key infrastructure is the whole tree of these signatures, each authority signing the layer below it up to a trusted root.
3. Challenge-response. Presenting a static secret can be replayed by anyone who captures it, so strong protocols make the prover demonstrate control of a private key live, without revealing it. The verifier sends a fresh random challenge, and the prover returns a signature over that challenge. A recording is useless next time because the challenge changes, which is how the TLS handshake and SSH authenticate a server or a user on every connection.

Put together, these turn identity into something you can prove to a party you’ve never met. When your browser sees the padlock, a chain of signatures has authenticated the server: the site proved control of its private key by signing a fresh challenge, its certificate binds that key to the domain name, and a Certificate Authority your browser trusts signed the certificate. Every link in that chain is a signature.

Mechanism	What it authenticates	How it proves identity	Where you meet it
Digital signature	The holder of a private key	Only the private key can produce a signature the public key verifies	Code signing, tokens, documents
Certificate + PKI	A named entity (domain, person, device)	A trusted authority signs a binding of key to name	The browser padlock, TLS, device identity
Challenge-response	Live control of a private key	The prover signs a fresh random challenge each time	TLS handshake, SSH login

Where does authentication live?

Authentication is woven through so much infrastructure that most of it runs invisibly until it fails. The high-stakes surfaces where cryptography does the proving:

1. The web and TLS. Every certificate behind the browser padlock authenticates a server to a visitor, and mutual TLS (mTLS) authenticates both ends of a machine-to-machine connection.
2. Federated identity and single sign-on. Signed tokens like JWTs and SAML assertions let an identity provider authenticate a user once and have many applications trust that assertion, which is what holds SSO together.
3. Device and workload identity. Certificates authenticate servers, IoT devices, and cloud workloads to each other, so a service knows it’s talking to a genuine peer rather than an impostor.
4. Code and firmware. Secure boot and software updates authenticate the publisher through a signature before trusting the code, which is what separates a legitimate update from malware wearing its name.
5. Remote access. SSH host keys and user keys authenticate servers and administrators, gating the doors into infrastructure.

The through-line is that all of the high-scale, high-stakes authentication runs on public-key cryptography, on signatures and certificates rather than on passwords. That’s exactly the cryptography a quantum computer comes for.

How does the quantum threat break authentication?

A large quantum computer breaks certificate-based authentication by forging the signatures it rests on. The classical signature algorithms behind every certificate, RSA and ECDSA, get their security from problems (integer factorization and the elliptic-curve discrete logarithm problem) that Shor’s algorithm solves efficiently. Feed Shor’s algorithm a public key, and it returns the matching private key. Once an attacker holds the private key, they hold the identity: they can sign anything that key was trusted to sign, mint certificates that pass verification, and impersonate the service the certificate names.

This is a Non-HNDL threat, and the distinction changes how you reason about the clock:

1. It targets trust, and it’s real-time. Harvest Now, Decrypt Later is about recording encrypted data today to decrypt after a quantum computer arrives, so the confidentiality damage is retroactive. Forging an identity has nothing to record. The attack happens live, once the machine exists, and a forged authentication that succeeds is undetectable at the moment it matters.
2. The target material is already public. The public key an attacker needs is published by design, sitting inside every certificate and token in the open. There’s no traffic to intercept and no vault to breach, the attacker already has the input and is only waiting on the machine.
3. The worst case is total. Breaking a single root Certificate Authority’s signing key makes every certificate beneath it forgeable at once. That’s PKI collapse, where a forger can impersonate any service in a whole trust domain, and the trust anchor the internet leans on becomes a skeleton key in the wrong hands.

Because migrating this infrastructure (rebuilding certificate hierarchies, distributing new roots, updating trust stores across billions of devices) takes years, the deadline is set by how long that work takes rather than by when the machine arrives, which is the logic of Mosca’s theorem. The fix is to move the authentication layer onto post-quantum signatures, ML-DSA for general-purpose signing and SLH-DSA for conservative long-lived roots of trust, usually staged with hybrid or composite certificates so verifiers upgrade at their own pace. Enlarging an RSA key buys almost nothing against Shor’s algorithm, so this is an algorithm swap and not a key-size adjustment.

Source: P. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Computing, 1997, quant-ph/9508027.

Source: NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, August 2024, FIPS 204.

Has this happened before?

Authentication failing not because the math broke but because a system trusted a valid credential in the wrong hands is an old story, and one of the clearest accounts is Cliff Stoll’s The Cuckoo’s Egg. In 1986 Stoll, an astronomer working as a systems manager at Lawrence Berkeley National Laboratory, chased down a 75-cent accounting discrepancy and found an intruder moving through the lab’s computers and out across military and research networks.

The intruder authenticated as legitimate users the whole way, using stolen and guessed credentials, and every system he touched believed him, because he presented valid logins and the machines had no way to tell an authorized user from an impostor holding an authorized user’s credential. Stoll traced the thread for months to a West German hacker, Markus Hess, who was selling what he found to the Soviet KGB.

The lesson lines up exactly with the quantum problem. Authentication proves control of a credential, and a valid credential in a thief’s hands still passes. Stoll’s intruder held stolen passwords; a quantum forger holds a private key reconstructed from a public one. In both cases the credential checks out and the identity behind it is a lie, which is why the whole post-quantum effort on this front is about keeping the credential itself impossible to forge.

Source: Cliff Stoll, The Cuckoo’s Egg: Tracking a Spy Through the Maze of Computer Espionage, Doubleday, 1989.

Common misconceptions

1. “Authentication and authorization are the same thing.” Authentication proves who you are; authorization decides what you’re allowed to do. A system can authenticate you correctly and still refuse the action, and the two use different machinery.
2. “A password proves who you are.” A password proves control of a secret, which can be phished, reused, guessed, or shared. That’s why phishing-resistant factors and multi-factor authentication exist, to raise the bar above a single stealable secret.
3. “MFA makes an account unhackable.” MFA raises the cost substantially, and it defeats stolen-password attacks, but it’s not absolute. Phishing proxies, push-fatigue, and SIM-swap attacks can still defeat weaker factors, which is why phishing-resistant hardware keys are the strong tier.
4. “A valid certificate means the site is safe.” A valid certificate proves control of the key and that a trusted authority vouched for the name. It says nothing about whether the operator is honest, which is a separate trust question that authentication doesn’t answer.
5. “Quantum breaks authentication by stealing passwords.” Passwords aren’t the quantum target. The threat is to the public-key signatures behind certificates: Shor’s algorithm forges the cryptographic identity layer, letting an attacker impersonate a service without touching anyone’s password.
6. “A bigger key will protect certificate authentication from quantum.” For RSA and elliptic-curve signatures, larger keys buy almost nothing against Shor’s algorithm. The fix is switching to a post-quantum signature algorithm, not enlarging a classical one.

Questions people ask

What’s the difference between authentication and authorization? Authentication verifies identity, who you are, and always runs first. Authorization grants permissions, what you’re allowed to do once you’re known. A correct login can still be followed by a denied action, because the two are separate decisions on separate machinery.

What are the three authentication factors? Something you know (a password or PIN), something you have (a hardware key or phone), and something you are (a biometric like a fingerprint or face). Combining factors from different categories is multi-factor authentication, and it’s stronger because an attacker has to defeat two independent kinds of evidence.

Is MFA the same as two-factor authentication? Two-factor authentication (2FA) is multi-factor authentication with exactly two factors, so every 2FA setup is MFA, and MFA is the broader term that also covers three or more factors. The strength depends far more on which factors you combine than on the count, a phishing-resistant hardware key adds much more than an SMS code.

How does a website prove its identity to my browser? During the TLS handshake the server presents a certificate binding its public key to its domain name, then proves it controls the matching private key by signing a fresh challenge. Your browser checks that a Certificate Authority it already trusts signed the certificate, so a chain of signatures authenticates the server without you and the site ever sharing a secret in advance.

Does the quantum threat let attackers steal my password? No, that’s a different attack surface. The quantum threat forges the public-key signatures behind certificates, which lets an attacker impersonate a trusted service or mint fake certificates. Password theft is a phishing and credential-management problem, and it isn’t what a quantum computer solves.

Which authentication systems are most exposed to the quantum threat? Anything that authenticates through public-key certificates and signatures: TLS and web PKI, code and firmware signing, device and workload identity, and federated-identity tokens. The roots of trust (Certificate Authorities, firmware anchors) are the highest-stakes, because forging a root key enables PKI collapse across everything beneath it.

Do I need to replace my authentication systems right now? Not overnight, but the certificate and signature infrastructure behind authentication is exactly what takes the longest to migrate, so it’s the part to inventory and sequence first. NIST’s roadmap disallows classical signature algorithms for federal use by 2035, and the roots of trust start earliest because they’re the slowest to rotate.

What replaces the cryptography behind authentication? The classical signatures (RSA, ECDSA) that authenticate certificates get replaced by post-quantum signature standards: ML-DSA for general-purpose signing and SLH-DSA for conservative long-lived roots of trust. Passwords and biometrics aren’t the quantum concern, so they carry on as they are.

Are passkeys and passwordless login quantum-safe? Not yet. Passwordless authentication (FIDO2, WebAuthn, and passkeys) removes the shared password secret and proves identity by signing with a classical ECDSA, EdDSA, or RSA key, so it carries a signature’s quantum exposure. The fix is post-quantum signatures (ML-DSA) in the same credentials, which the FIDO Alliance is scoping.

---

Everything here is the map, given freely. When your team needs the authentication cryptography across its own certificates, tokens, and devices found, sized, and sequenced onto a post-quantum path, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.