The Evolution of Authentication

From Local Passwords to Federated, Hardware-Backed Identity

A Standards-Referenced Technical Reference and Timeline: 1990s to the Modern Era

CyberCQR White Paper · Version 3.0

Executive Overview

Authentication is the act of proving an identity. Over three decades it has shifted from a single secret typed into a device, to a hardware-anchored cryptographic ceremony in which the secret never leaves the chip that holds it. Understanding this trajectory matters because most security incidents still turn on credentials: stolen passwords, replayed sessions, phished one-time codes, hijacked session tokens, and over-privileged service accounts.

This document traces the methods chronologically, from passwords stored locally on a device — such as a router, a switch, or an Internet-of-Things sensor — through centralised network authentication, hardware tokens, federation and single sign-on, and finally to the modern model in which a Trusted Platform Module (TPM) or secure element holds a private key on the device and proves identity to a cloud identity provider.

The most important conceptual shift, and the section treated in greatest depth, concerns how modern devices authenticate. A common misunderstanding is that the PIN a user types into a laptop or phone is the credential that signs them in. It is not. The PIN unlocks local use of a cryptographic key held in hardware; it is the key, never the PIN, that authenticates to the identity provider, and the PIN never travels across the network.

This revision is deliberately evidential and operational. Claims are tied to the relevant standards — NIST, IETF RFCs, W3C, the FIDO Alliance, the Trusted Computing Group, and IEEE^{1,2,3,12,13,14,15} — and the analysis includes a candid treatment of how modern identity is actually attacked, drawing on real incidents at Uber, Okta, and through the SolarWinds campaign^18,19,20. It also states plainly where hardware-backed, passwordless authentication does not solve the problem, because the frontier has moved to session tokens, account recovery, and trust in the identity provider itself.

How to read this document. Parts 1–2 establish the timeline and vocabulary. Parts 3–7 walk through each historical era. Part 8 is the detailed treatment of TPM-based identity and the role of the PIN. Parts 9–10 cover FIDO2, passkeys, and the full federated flow. Parts 11–13 cover the modern attack landscape, a method-by-method attacks-and-mitigations reference, and the honest limits of passwordless. Parts 14–15 cover cross-platform implementation and operational migration. A comparison table and full references close the document.

Part 1: A Timeline of Authentication

The evolution of authentication is best understood as a series of responses to the failures of the method that preceded it. Each era solved a real problem and, in doing so, exposed the next one.

Two threads run through the whole timeline. The first is the steady migration of the secret away from places where it can be stolen: from plaintext on disk, to salted hashes, to a server you authenticate against, to a key in tamper-resistant hardware that performs operations without ever revealing itself. The second is the separation of the human gesture (a password, a PIN, a fingerprint) from the thing that actually authenticates (increasingly, a cryptographic signature). As Part 11 shows, attackers have followed the secret at every step — and where they can no longer steal the credential, they now target the session it produces.

Part 2: Foundational Concepts

2.1 The Factors of Authentication

Every method draws on one or more of three classic factors, plus two modern contextual signals:

• Something you know: a password, passphrase, or PIN.

• Something you have: a phone, a smart card, a security key, or a device whose hardware holds a key.

• Something you are: a biometric — fingerprint, face, or iris.

• Somewhere you are: network, geography, and device location, used as a contextual signal.

• Something you do: behavioural patterns such as typing cadence or usage rhythm.

Multi-factor authentication (MFA) means combining factors from different categories, so that compromising one (a stolen password) does not by itself grant access. As later parts show, the modern model delivers genuine multi-factor strength even when the user experiences it as simply typing a PIN.

2.2 Shared Secrets versus Cryptographic Keys

Authentication’s whole evolution turns on one distinction: a shared secret versus an asymmetric key pair. Replacing the former with the latter is, in effect, the entire story.

Shared secret. A value that both sides must know — the classic password. The user knows it and the server stores a representation of it. Both copies are attackable: the user can be phished, the transmission can be intercepted, and the server’s store can be breached. Because the same secret is presented every time, a captured copy can be replayed.

Asymmetric key pair. A mathematically linked pair: a private key that never leaves the holder, and a public key that can be shared freely. The holder proves identity by signing a fresh, server-supplied challenge with the private key; the server verifies the signature with the public key. The server never holds anything secret, nothing reusable crosses the network, and a captured signature cannot be replayed because the next challenge is different.

Symmetric cryptography uses one shared key for both encryption and decryption (fast, but both sides hold the same secret). Asymmetric (public-key) cryptography uses the key pair described above. Modern device authentication is built on asymmetric keys held in hardware — this is what makes the private key non-exportable and the scheme resistant to theft.

2.3 Authentication, Authorisation, and Federation

• Authentication establishes who you are.

• Authorisation establishes what you may do once identified.

• Federation lets one system (an identity provider) vouch for an identity to another system (a relying party or service provider) that trusts it, so the user need not hold separate credentials everywhere.

The modern model authenticates locally on the device using a hardware key, then federates that proof to a cloud identity provider, which in turn authorises access to many downstream services. Each later part adds one piece of this chain — and Part 11 shows how attackers target each piece in turn.

Part 3: The Local Credential Era (1990s)

3.1 Passwords Stored on the Device

In the earliest networked systems, each device was an island. A server, a workstation, a router, or an industrial controller held its own list of usernames and passwords. To log in, you presented a username and password; the device compared them against its local store and, if they matched, granted access for the duration of a session.

On Unix-like systems this store was the /etc/passwd file, later split so that password hashes lived in the shadow-protected /etc/shadow. Early systems stored passwords in plaintext or with weak, unsalted hashes; anyone who could read the file could recover or crack the credentials. Salting and stronger one-way hash functions made stored credentials harder to reverse, but the fundamental model remained: a secret, compared locally, granting a long-lived session.

3.2 Network Equipment and IoT: Local User Databases and Config-Stored Credentials

Network and embedded devices took the same approach, and many still do. A router or switch typically holds a small local user database and one or more privileged passwords inside its configuration — historically a login password and a separate “enable” secret for privileged mode, stored in reversible or lightly obfuscated form and later as proper hashes. The device itself performs the comparison.

Internet-of-Things devices — cameras, sensors, controllers, consumer appliances — inherited this pattern at enormous scale. Many shipped with default credentials baked into firmware, identical across every unit of a model and documented in manuals that attackers read as readily as administrators. Where credentials were stored in flash, anyone with physical access or a firmware dump could extract them. Because the same secret was reused across an entire product line, compromising one device often meant compromising all of them — the raw material for some of the largest botnets ever assembled.

Why this mattered. Local, device-stored credentials do not scale and do not revoke. An organisation with thousands of devices has thousands of independent credential stores. When a password must change, every device must be touched. When an administrator leaves, their access may linger on equipment everyone has forgotten.

3.3 Plaintext Transport and the Interception Problem

Compounding local storage was the way credentials travelled. Telnet, FTP, and early HTTP transmitted usernames and passwords in plaintext; anyone observing the traffic could capture them. The move to encrypted transports (SSH replacing Telnet, TLS protecting web and mail) closed the interception gap for data in motion, but did nothing to change the underlying reliance on a reusable shared secret.

Part 4: Centralised and Networked Authentication

The unmanageability of per-device credentials drove the first great consolidation: move the decision of who may log in to a central authority that many devices consult. This is the origin of AAA — Authentication, Authorisation, and Accounting — and of the enterprise directory.

4.1 RADIUS and TACACS+ for Network Access and Administration

Two protocols dominate AAA for network and embedded infrastructure, and they are frequently confused. Both are client-server protocols that let a device (the “client”, such as a switch, VPN concentrator, or wireless controller) hand the login decision to a central server backed by a directory. Both provide authentication, authorisation, and accounting, and both let an organisation manage access centrally rather than on every device. But they were designed for different jobs, and the differences are practical, not cosmetic.

What RADIUS offers. RADIUS (Remote Authentication Dial-In User Service) is an open IETF standard³. It runs over UDP, and in a single request-response exchange it both authenticates the user and returns authorisation attributes (the access the user is granted). Critically, it encrypts only the user’s password within the packet; the remaining attributes travel in cleartext. RADIUS is the workhorse of network access — it underpins 802.1X port security, Wi-Fi (WPA2/3-Enterprise), and VPN logins, and it carries the EAP methods used for certificate- and token-based network authentication. Its broad, multi-vendor support is a large part of why it became ubiquitous.

What TACACS+ offers. TACACS+ (Terminal Access Controller Access-Control System Plus) originated at Cisco and is now documented as an open protocol⁴. It runs over TCP and obfuscates the entire packet body, not just the password. Its defining feature is that it separates authentication, authorisation, and accounting into distinct exchanges, which enables fine-grained, per-command authorisation — deciding not just whether an administrator may log in to a router, but exactly which commands they may run once there. This makes TACACS+ the natural choice for device administration of routers, switches, and firewalls.

Similar but different. Both centralise AAA and remove per-device credential stores, but they specialise: RADIUS for users connecting to the network, TACACS+ for administrators managing the network devices themselves. Many organisations run both — RADIUS for access, TACACS+ for administration. The table summarises the distinctions.

A word on confidentiality: because RADIUS leaves most attributes in cleartext and relies on MD5, it has well-known weaknesses, including the 2024 “Blast-RADIUS” forgery attack²³ covered in Part 12. TACACS+’s full-body obfuscation is stronger but still depends on a shared secret. Both are increasingly deployed over TLS for genuine protection.

4.2 Kerberos: Tickets Instead of Repeated Passwords

Kerberos, developed at MIT and standardised in its widely used version 5, introduced a more sophisticated idea: the user authenticates once to a central Key Distribution Centre and receives a time-limited, cryptographically protected ticket, which is then presented to individual services that trust it without ever seeing the password⁵. It became the authentication backbone of Windows domains.

Kerberos foreshadowed two ideas that dominate later: authenticate once and reuse a protected token, and keep the long-term secret away from the services being accessed. Its weaknesses — reliance on shared symmetric keys, sensitivity to clock skew, and attacks against service-account tickets — are precisely the issues that asymmetric, hardware-backed methods later addressed.

4.3 LDAP, NTLM, and Active Directory

Directories provided the central store these protocols needed. LDAP standardised how systems query a directory of users, groups, and attributes⁶. Microsoft’s Active Directory combined an LDAP directory with Kerberos and the older NTLM challenge-response protocol into the dominant enterprise identity platform.

This era achieved central management, group-based authorisation, and a single account per user across many systems. What it did not change was the credential itself: at the bottom of the stack was still a password — now defended by a central server, but still phishable, guessable, reusable, and replayable if captured.

4.4 802.1X: Authenticating the Connection Itself

IEEE 802.1X extended central authentication to the network port and the wireless association, requiring a device or user to authenticate (typically via RADIUS and the EAP framework) before being granted network access at all¹². This laid the groundwork for certificate-based device identity, where a device proves itself with an issued credential rather than a shared password — an early move toward the hardware-backed model.

Part 5: Hardware Tokens and One-Time Passwords

Central directories solved management but not the fragility of the password. The next response added a second factor and, importantly, secrets that changed with every use.

5.1 Hardware Tokens and One-Time Passwords

RSA SecurID and similar tokens gave each user a small device displaying a number that changed every minute, derived from a secret seed shared with the authentication server and the current time. To log in, the user supplied their password plus the current token value. Even if the password were stolen, an attacker would also need the physically present token, and a captured value expired almost immediately.

This pattern was later standardised and made free: HOTP generates codes from a counter⁷, and TOTP generates them from the clock⁸. TOTP is what authenticator apps implement — the familiar six-digit code refreshing every thirty seconds. One-time passwords were a genuine advance: the secret on the wire is single-use, defeating simple replay.

5.2 Smart Cards and Public-Key Infrastructure

In parallel, smart cards and PKI introduced asymmetric keys to authentication. A smart card held a private key in tamper-resistant hardware and a certificate binding the corresponding public key to an identity, issued by a trusted certificate authority. The card signed a challenge to prove possession of the key without revealing it. This is, in essence, the same principle that TPMs and FIDO2 authenticators use today; smart cards proved the model but were costly to deploy, dependent on readers and middleware, and awkward outside controlled enterprise environments.

5.3 The Limit That Remained: Phishing

One-time passwords reduced replay but did not stop phishing. A fraudulent site can ask a victim for both their password and their current OTP and relay them to the real service within the valid window — a real-time, adversary-in-the-middle attack examined in detail in Part 11. Because the user is willing to type the code into whatever page asks for it, the human remains the weak point. Removing that weakness required binding authentication to the legitimate site cryptographically, so that a credential simply will not work anywhere else.

Part 6: Federation and Single Sign-On

As organisations adopted many web and cloud applications, asking users to hold a separate account for each became untenable and insecure. Federation lets a user authenticate once to a trusted identity provider and then access many independent services, each of which trusts assertions from that provider rather than storing its own credentials.

6.1 SAML

Security Assertion Markup Language (SAML), with its widely adopted 2.0 version, defined an XML-based way for an identity provider to make signed assertions about a user to a service provider¹¹. When a user visits a SAML-protected application, they are redirected to their identity provider, authenticate there, and return with a signed assertion the application validates and trusts. SAML became the workhorse of enterprise web single sign-on — and, as Part 11 shows, the signing key that makes it work became a prime attacker target.

6.2 OAuth 2.0

OAuth 2.0 addressed a different but related problem: delegated authorisation⁹. It lets a user grant one application limited access to their data in another — for example, allowing a tool to read a calendar — by issuing scoped access tokens, without sharing the underlying password. OAuth is about authorisation, and it became the foundation for the layer above it.

6.3 OpenID Connect

OpenID Connect added an authentication and identity layer on top of OAuth 2.0¹⁰. It introduced the ID token — a signed JSON Web Token containing verified claims about the user, such as their identifier and how they authenticated. It is what powers modern “sign in with” experiences and is the protocol most contemporary cloud identity providers use to authenticate users to applications.

The relying-party model. In all federation, the service being accessed does not authenticate the user itself; it trusts a signed token or assertion from the identity provider. This is powerful — one strong authentication can secure hundreds of applications — but it concentrates risk: the strength of every downstream service now depends on the strength of authentication to, and the integrity of, the identity provider. That is exactly why making that one authentication phishing-resistant and hardware-backed became the priority, and why the identity provider itself is now a primary target (Parts 11–13).

Part 7: Multi-Factor Authentication and Its Limits

Through the 2010s, multi-factor authentication reached ordinary users. Common second factors included SMS one-time codes, authenticator-app codes (TOTP), and push approvals where the user taps “approve” on their phone. Each meaningfully raised the cost of attack: a stolen password alone no longer sufficed.

But each retained weaknesses. SMS codes can be intercepted through SIM-swap fraud or signalling-network (SS7) attacks. TOTP codes and push approvals can be captured or coerced by adversary-in-the-middle phishing sites and by “MFA fatigue” — bombarding a user with approval prompts until one is tapped out of annoyance. The common flaw is that these factors are not bound to the legitimate website or service. The user, or a relay controlled by an attacker, can present them to the wrong destination.

The resolution is to make the credential refuse to work anywhere except the genuine service, and to keep the secret entirely out of human hands so it cannot be entered into a fraudulent page. This is achieved by binding a private key, held in device hardware, to the specific service. Recognising this, NIST’s 2025 Digital Identity Guidelines make phishing-resistant authenticators — notably FIDO/WebAuthn credentials and passkeys — the expected baseline for higher assurance levels¹.

Part 8: Modern Device-Based Authentication and the TPM

This part is the centre of the document. It explains what a Trusted Platform Module does, how a modern device holds and protects identity locally, the precise role of the PIN, and how local proof is passed to a cloud identity provider. Windows Hello for Business is the worked example because it is widely deployed and well documented; Apple’s Secure Enclave and Android’s hardware-backed keystore follow the same principles (Part 14).

8.1 What a TPM Is

A Trusted Platform Module is a dedicated, tamper-resistant cryptographic component that provides a hardware root of trust on the device. It exists either as a discrete chip or as firmware running in a protected execution environment of the main processor (a firmware TPM). TPM 2.0 is the current standard¹⁵ and is a baseline requirement of recent operating systems. For authentication, the essential capabilities are these:

• It generates key pairs internally. The private key is created inside the TPM and is marked non-exportable, meaning it can never be read out of the chip in usable form.

• It performs cryptographic operations on the device’s behalf. Signing and decryption happen inside the TPM; the private key is never exposed to the operating system, to memory, or to any application.

• It binds keys to authorisation conditions. A key can be configured so it is used only when a correct authorisation value (such as the user’s PIN) is supplied, and only on this physical device.

• It resists brute force through anti-hammering. After a number of incorrect authorisation attempts, the TPM enters a lockout that escalates with each failure, making it infeasible to guess a PIN by repetition.

• It can attest to its own state and keys. Through key attestation and measured-boot registers, a TPM can prove that a key genuinely lives in a real, healthy TPM — not in software — which the identity provider can require during registration.

The result is a secret that is genuinely hard to steal. Even an attacker with full administrative control of the running operating system cannot extract the private key, because it never exists outside the chip. (Physical and side-channel attacks against TPMs do exist and are discussed honestly in Parts 12 and 13.)

8.2 The Central Point: The PIN Is Not the Credential

This is the most misunderstood aspect of modern authentication, and the point this document exists to make clearly.

The PIN does not sign you in. The PIN is not transmitted to the identity provider, is not compared against anything in the cloud, and is not the secret that authenticates you. The PIN is a local authorisation gesture: it unlocks the use of the private key that lives inside the TPM. It is the cryptographic key — by signing a challenge — that proves your identity. The PIN is simply how you, the legitimate holder of the device, tell the TPM that it may use the key on your behalf right now.

Several consequences follow:

• The PIN is device-local. A given PIN only has meaning on the specific device whose TPM holds the matching key. The same digits typed into any other device authenticate nothing. This is why a PIN can be short and simple while remaining strong — it is not a password defending a remote account.

• The PIN never crosses the network. Because it is never sent anywhere, it cannot be intercepted in transit, cannot be captured by a phishing site, and cannot be stolen from a breached server. There is no server-side store of PINs to compromise.

• Knowing the PIN is useless without the device. An attacker who learns the PIN by shoulder-surfing still cannot authenticate, because the private key resides in that one device’s TPM and cannot be copied out.

• This is genuinely multi-factor. Authentication requires something you have (the device, holding the TPM-bound private key) and something you know (the PIN) or something you are (a biometric that unlocks the key the same way). The user experiences a single gesture, but two factors are satisfied.

A biometric — a fingerprint or face — plays exactly the same role as the PIN: it is a local gesture that authorises the TPM to use the private key. The biometric template is matched locally on the device and is never sent to the identity provider either. Biometric and PIN are interchangeable unlock methods for the same underlying key.

8.3 Provisioning: How the Key and PIN Are Established

Before any sign-in can happen, the device must be enrolled. Registration establishes the key pair and ties the public half to the user’s account at the identity provider.

1. Initial strong authentication. The user first proves who they are to the identity provider through an existing trusted method (for example, existing multi-factor authentication). This bootstraps trust for the new device.

2. Key-pair generation in the TPM. The device instructs the TPM to generate a fresh asymmetric key pair. The private key is created inside the TPM as a non-exportable key and never leaves it.

3. Binding the key to a local gesture. The user sets a PIN (or enrols a biometric). This gesture is configured as the authorisation the TPM will require before using the private key. It is stored and evaluated only by the device’s hardware; it is not uploaded.

4. Optional key attestation. The TPM can produce attestation proving the key genuinely resides in a real TPM. The identity provider may require this so that only hardware-protected keys are accepted.

5. Registering the public key. The device sends the public key (and any attestation) to the identity provider, which associates it with the user’s account¹⁶. The provider now holds only the public key — a value that is not secret and is useless to an attacker.

After provisioning, the identity provider knows: this user has a device whose TPM holds a private key, and here is the matching public key with which to verify that device’s signatures. No shared secret exists between device and provider.

8.4 Authentication: How Sign-In Actually Works

With provisioning complete, day-to-day sign-in is a challenge-response ceremony. Follow the path of trust carefully, because it shows exactly where the PIN acts and where the key acts.

1. The user makes the local gesture. The user enters their PIN or presents a biometric. This is evaluated entirely on the device. If correct, it authorises — but does not itself perform — use of the private key.

2. The TPM unlocks use of the private key. Having received valid authorisation, the TPM permits the private key to be used for one operation. Anti-hammering protects this step: repeated wrong PINs trigger lockout.

3. A challenge is issued. The identity provider (or the local credential provider acting on its behalf) supplies a fresh, unpredictable challenge — a nonce — that is different every time.

4. The TPM signs the challenge. Inside the chip, the private key signs the challenge. The signing happens within the TPM; the private key is never exposed to the operating system or memory.

5. The signed assertion is sent. The device transmits the signature to the identity provider. Note what travels: a one-time signature over a one-time challenge. No password, no PIN, nothing reusable.

6. The provider verifies with the public key. The identity provider checks the signature against the registered public key. A valid signature proves the request came from the device holding the matching private key, and that the legitimate user authorised it.

7. Tokens are issued. On success, the provider issues a token of access — in Microsoft Entra, for example, a Primary Refresh Token bound to the device and its TPM¹⁶ — which is then used to obtain further tokens for individual applications without repeating the full ceremony. (As Part 11 shows, this token is now the thing attackers try to steal.)

Where the PIN was, and was not. Trace the seven steps: the PIN appeared only in step 1, locally, to authorise the TPM. From step 3 onward, everything that crossed the network was a cryptographic signature over a server-chosen challenge. The PIN never left the device. This is why the scheme defeats phishing (there is no reusable secret to phish), replay (each challenge is unique), and server breach (the provider stores only public keys).

8.5 Why the Private Key Cannot Be Stolen or Replayed

• Non-exportable keys. The private key is generated in and confined to the TPM; there is no operation that returns it in usable form, even to an administrator.

• Operations stay inside the chip. Because signing occurs within the TPM, the key is never present in system memory where malware could scrape it.

• Challenge freshness defeats replay. A signature is valid only for the specific challenge it covers. Capturing one signature yields nothing reusable.

• Anti-hammering defeats guessing. Escalating lockouts make exhaustive PIN guessing infeasible.

• Device binding. Tokens such as the Primary Refresh Token are themselves bound to the device and its TPM, so even a stolen token is harder to use elsewhere — though, as Part 13 explains, not impossible.

8.6 Windows Hello for Business: Key Trust, Certificate Trust, and Cloud Trust

Windows Hello for Business implements the model above and supports more than one trust arrangement for working with on-premises Active Directory alongside the cloud¹⁶. In the key-trust model, the raw public key is registered and used directly. In the certificate-trust model, the TPM-protected key underpins a certificate issued to the user, used with existing certificate-aware infrastructure such as Kerberos. Cloud-trust deployments simplify this while keeping the same TPM-backed key at the centre. In every variant the defining property is unchanged: a hardware-protected private key signs the proof, and the user’s PIN or biometric only unlocks its use locally.

Part 9: FIDO2, WebAuthn, and Passkeys

The same hardware-backed, challenge-response principle has been standardised for the open web through FIDO2, which combines the W3C WebAuthn standard (a browser and platform API, a Recommendation since 2019 and updated in 2021) with the FIDO Alliance’s CTAP protocol for talking to authenticators^13,14.

9.1 How FIDO2 Works

When a user registers with a website, their authenticator generates a new key pair specific to that site’s origin. The private key stays in the authenticator; the public key is sent to the website and stored against the account. To sign in, the website sends a challenge, the authenticator signs it after a local user gesture (touch, PIN, or biometric), and the website verifies the signature with the stored public key. The credential is cryptographically bound to the legitimate site’s origin, so it cannot be used on a look-alike phishing domain — the browser will not release a signature for the wrong origin. This origin binding is what makes FIDO2 phishing-resistant where OTP and push are not.

9.2 Platform and Roaming Authenticators

• Platform authenticators are built into the device — the laptop or phone — and use the TPM or secure enclave to hold the keys. This is the same hardware described in Part 8, exposed to the web.

• Roaming authenticators are separate hardware security keys (for example, USB or NFC keys) that can be carried between devices and hold the private keys themselves.

9.3 Passkeys

A passkey is a FIDO2 credential made user-friendly. Device-bound passkeys remain in a single device’s hardware. Synced passkeys are backed up and shared across a user’s devices through a provider’s end-to-end-encrypted cloud (such as a platform keychain), so that losing one device does not lose the credential. NIST’s 2025 guidance explicitly recognises both forms as acceptable phishing-resistant authenticators¹. In both cases the private key is hardware-protected on the devices that hold it, authentication is challenge-response, and the credential is origin-bound. Synced passkeys, however, introduce their own considerations around the sync account and recovery, addressed in Part 13.

Part 10: Federated, Hardware-Backed Identity End to End

The full modern flow assembles every thread of this document. It begins with a local gesture and a hardware key, and ends with conditional, federated access to many services — without a shared password anywhere.

1. Local unlock. The user makes a gesture — PIN or biometric — that authorises the device’s TPM to use its private key. Nothing leaves the device yet.

2. Cryptographic proof to the identity provider. The device signs a fresh challenge with the TPM-held key. The identity provider verifies it against the registered public key, as in Part 8.

3. Device and posture evaluation. Alongside the cryptographic proof, the provider evaluates context — is the device managed and compliant, is the location and risk acceptable — and applies conditional access policies, in line with Zero Trust’s per-request model².

4. Issue of a federated token. The provider issues a token (such as a Primary Refresh Token, or an OpenID Connect ID token for an application) that represents the authenticated, device-bound session.

5. Single sign-on to services. Using that token, the user obtains scoped tokens for individual applications via OpenID Connect and OAuth, accessing many services without re-authenticating, while each service trusts the provider’s signed tokens.

6. Continuous re-evaluation. Modern providers can re-check risk and revoke access mid-session if signals change, rather than trusting a token blindly until it expires.

The result reconciles the two goals earlier eras could not satisfy at once: strong, phishing-resistant proof of identity, and frictionless access across many systems. The strength comes from the hardware key and challenge-response; the convenience comes from federation. But notice that steps 4 and 5 produce bearer tokens — and that is where the modern attacker now concentrates, as the next part shows.

Part 11: The Modern Identity Threat Model

A reference that explains only how authentication is supposed to work is incomplete. This part describes how identity is actually attacked today, with real incidents, and maps the techniques so defenders can reason about them. The through-line is simple: as login itself became harder to phish, attackers moved to the artefacts login produces — sessions, tokens, recovery paths, and the identity provider’s own trust.

11.1 Why Attackers Shifted to Identity

Endpoint and network defences improved faster than identity did. Stealing a valid identity — or the session that follows authentication — is quieter than deploying malware and often bypasses controls entirely, because the activity looks like a legitimate user. The result is that credential and session abuse, not exotic exploits, underpin most modern breaches.

11.2 Adversary-in-the-Middle (AiTM) Phishing

The dominant phishing technique is no longer a static fake login page but a reverse-proxy that sits between the victim and the real service. Toolkits such as Evilginx and commercial “phishing-as-a-service” kits relay the victim’s credentials and second factor to the genuine site in real time, then capture the resulting session cookie. This defeats passwords, SMS codes, TOTP, and push approval alike, because the victim really does authenticate — to a proxy. It does not defeat origin-bound FIDO2/WebAuthn, because the browser will not release a signature to the attacker’s domain. This is the single strongest practical argument for phishing-resistant authenticators.

11.3 Session Token and Cookie Theft (“Pass-the-Cookie”)

Once a user authenticates, the resulting session cookie or token is itself a bearer credential: whoever holds it is treated as the user, often without re-authentication. Attackers steal these through AiTM proxies, through infostealer malware on the endpoint, and — strikingly — from places they are inadvertently stored. MITRE ATT&CK catalogues this as stealing and re-using web session cookies¹⁷.

Case study — Okta customer support system, 2023. Between late September and mid-October 2023, an attacker used a service-account credential inside Okta’s support case-management system to read diagnostic HAR files that customers had uploaded. Some of those files still contained live session tokens, which the attacker replayed to hijack the Okta sessions of several customers, including BeyondTrust, 1Password, and Cloudflare¹⁹. Notably, the targeted BeyondTrust administrator account was protected with FIDO2 — phishing-resistant login — yet a stolen post-authentication session token sidestepped that strength entirely. The lesson is central to Part 13: hardening login does not by itself protect the session it creates.

11.4 MFA Fatigue (Push Bombing)

Case study — Uber, September 2022. An attacker associated with the Lapsus$ group obtained an Uber contractor’s VPN credentials (reportedly purchased on a criminal marketplace) and then triggered a flood of push-approval prompts. When the contractor did not approve, the attacker contacted them directly, posing as Uber IT support, and urged them to accept one to stop the notifications. The contractor approved, granting access that was then escalated across internal systems¹⁸. The episode drove the industry toward number-matching and context-rich prompts, and ultimately toward phishing-resistant methods that cannot be “approved” by mistake.

11.5 Help-Desk Social Engineering and MFA Reset Abuse

If the login is hard to defeat, attackers attack the processes around it. Groups tracked as Scattered Spider have repeatedly phoned IT service desks, impersonated employees (using details gathered from social media and data brokers), and persuaded staff to reset passwords or enrol a new MFA device under the attacker’s control²². High-profile intrusions at major hospitality and gaming companies in 2023 began this way. Strong authenticators are only as strong as the recovery and enrolment paths that can replace them.

11.6 OAuth Consent Phishing and Illicit Grants

Rather than steal a password, an attacker can ask the user to grant a malicious application standing OAuth permissions — for example, persistent access to mailbox and files. The user authenticates legitimately (even with strong MFA) and clicks “allow.” The resulting refresh token gives durable access that survives password changes, because no password was ever the point. This abuses the delegated-authorisation model of Part 6 directly.

11.7 Device Registration and Token Theft

Two further techniques target the modern flow itself. In device-registration abuse, an attacker who has briefly compromised an account enrols their own device into the identity platform, establishing a durable, “trusted” foothold. In token theft, malware on an unlocked endpoint extracts the issued tokens — including, in some research and tooling, the Primary Refresh Token material or its associated cookie — and replays them elsewhere. Device binding raises the bar but does not make tokens inviolable on a compromised host.

11.8 Compromising Federation Itself

Case study — SolarWinds / Golden SAML, 2020. After gaining a foothold through the SolarWinds Orion supply-chain compromise, the attackers reached on-premises Active Directory Federation Services and stole the SAML token-signing certificate. With that private key they forged their own valid SAML assertions — impersonating any user, including administrators, in Microsoft 365 and other federated services — with no password, no MFA prompt, and no authentication event at the identity provider at all²⁰. This “Golden SAML” technique is the logical extreme of the relying-party model: trust the signing key, and you trust everything it signs. Its historical analogue is the 2011 RSA SecurID breach, in which attackers spear-phished their way into RSA and exfiltrated data related to the SecurID seed records that underpinned millions of tokens, undermining the second factor at its source²¹.

11.9 Technique Summary

The following maps each technique to what it targets and what actually stops it.

Part 12: Attacks, Exploits and Mitigations by Authentication Method

Part 11 described cross-cutting attacker methodology. This part is a method-by-method reference: for each authentication type in the timeline, the attacks and exploits it is exposed to, and the mitigations that address them. It is intended to be used as a checklist when assessing or hardening a specific control.

12.1 Local Passwords (Devices, IoT, Network Equipment)

Attacks & exploits:

• Default and hardcoded credentials — identical across a product line and documented publicly; the basis of large IoT botnets.

• Credential stuffing and brute force against exposed management interfaces.

• Offline cracking of weak or unsalted password hashes extracted from configs or firmware dumps.

• Plaintext interception over legacy protocols (Telnet, FTP, HTTP).

• Physical extraction of credentials from flash memory.

Mitigations:

• Unique per-device credentials; eliminate or change all defaults at provisioning.

• Strong, salted, adaptive password hashing (bcrypt, scrypt, Argon2).

• Encrypted management only (SSH, HTTPS); disable plaintext services.

• Account lockout and rate limiting; disable unused accounts.

• Migrate to centralised AAA or certificate-based device identity (Parts 4 and 13).

12.2 RADIUS

Attacks & exploits:

• The 2024 “Blast-RADIUS” forgery (CVE-2024-3596): an on-path attacker turns an Access-Reject into an Access-Accept via an MD5 chosen-prefix collision against the Response Authenticator, without knowing the shared secret²³.

• Shared-secret dictionary/brute-force attacks, aided by cleartext attributes and weak secrets.

• UDP response spoofing and replay where integrity is not enforced.

• Exposure of cleartext authorisation attributes to anyone on the path.

Mitigations:

• Require the Message-Authenticator attribute on all packets; apply vendor patches for CVE-2024-3596.

• Deploy RADIUS over TLS/DTLS (RadSec) for full confidentiality and integrity.

• Long, unique, high-entropy shared secrets per client; never reuse across devices.

• Isolate AAA traffic on a dedicated, anti-spoofed management network.

12.3 TACACS+

Attacks & exploits:

• Recovery of the obfuscated packet body if a weak or reused shared secret is compromised (the body relies on an MD5-derived keystream).

• Man-in-the-middle on the TCP session where the shared key is weak.

• A single shared key reused across many devices widening blast radius.

Mitigations:

• Strong, unique shared keys per device; rotate regularly.

• Restrict TACACS+ sources by ACL and segment the management network.

• Adopt TACACS+ over TLS where the platform supports it; monitor administrative sessions.

12.4 Kerberos

Attacks & exploits:

• Pass-the-Ticket: reusing stolen TGTs or service tickets.

• Golden Ticket: forging TGTs after compromising the krbtgt account key.

• Silver Ticket: forging service tickets with a captured service-account key.

• Kerberoasting: requesting service tickets to crack weak service-account passwords offline.

• AS-REP roasting against accounts with pre-authentication disabled.

Mitigations:

• Strong, long service-account passwords or group-Managed Service Accounts (gMSA).

• Rotate the krbtgt key periodically; protect Domain Controllers and Tier-0 assets.

• Disable RC4; require Kerberos pre-authentication; enforce least privilege and tiered administration.

• Monitor for anomalous ticket requests and encryption-type downgrades.

12.5 LDAP, NTLM and Active Directory

Attacks & exploits:

• LDAP injection against applications that build queries from untrusted input.

• Cleartext LDAP and anonymous binds exposing credentials and directory data.

• NTLM relay and pass-the-hash; LLMNR/NBT-NS poisoning to capture hashes.

Mitigations:

• LDAPS with LDAP signing and channel binding; disable anonymous bind.

• Disable or constrain NTLM; enforce SMB signing and Extended Protection for Authentication.

• Disable LLMNR/NBT-NS; parameterise and validate all LDAP queries.

12.6 One-Time Passwords (Hardware Tokens, TOTP)

Attacks & exploits:

• Real-time adversary-in-the-middle relay of the code to the genuine site.

• Seed/secret theft at the source, as in the 2011 RSA SecurID breach²¹.

• SIM-swap and SS7 interception for SMS-delivered codes.

• Shoulder-surfing and malware that reads codes on the device.

Mitigations:

• Prefer phishing-resistant authenticators (FIDO2/passkeys) for high-value access.

• Protect OTP seeds in an HSM; avoid SMS as a factor.

• Short validity windows; bind authentication to the legitimate origin where possible.

12.7 Smart Cards and PKI

Attacks & exploits:

• Theft of card plus PIN, or malware operating while the card is inserted.

• Certificate authority compromise or mis-issuance, enabling forged identities.

• Weak key storage or unrevoked, stolen certificates.

Mitigations:

• PIN with anti-hammering; remove card on absence; lock on idle.

• Protect the CA with HSMs and an offline root; enforce revocation (CRL/OCSP).

• Harden middleware; monitor issuance for anomalies.

12.8 SAML Federation

Attacks & exploits:

• Golden SAML: forging assertions with a stolen signing certificate, bypassing authentication and MFA entirely, as in the SolarWinds campaign²⁰.

• XML Signature Wrapping (XSW) to smuggle attacker-controlled assertions past validation.

• Assertion replay and audience/recipient confusion.

Mitigations:

• Protect and rotate signing keys in an HSM; treat the federation server as Tier-0.

• Strict, library-hardened signature validation to defeat XSW; enforce audience restriction and short assertion lifetimes.

• Monitor for tokens issued without a corresponding authentication event.

12.9 OAuth 2.0 and OpenID Connect

Attacks & exploits:

• Consent phishing / illicit grant: tricking a user into authorising a malicious application for durable access.

• Authorisation-code interception and open-redirect abuse.

• Refresh-token theft and reuse for persistent access surviving password changes.

Mitigations:

• Enforce PKCE and exact redirect-URI matching.

• Application and consent governance; admin approval for sensitive scopes; restrict third-party app registration.

• Short-lived, sender-constrained tokens (DPoP or mTLS); monitor and revoke anomalous grants.

12.10 Push and SMS Multi-Factor Authentication

Attacks & exploits:

• MFA fatigue / push bombing, as in the 2022 Uber compromise¹⁸.

• SIM-swap and SS7 interception of SMS codes.

• Adversary-in-the-middle relay of approvals and codes.

Mitigations:

• Number matching and context-rich prompts (location, app, device); rate-limit and alert on prompt floods.

• Retire SMS as a factor; move high-value users to phishing-resistant methods.

• Detect impossible travel and anomalous approval patterns.

12.11 TPM-Backed Sign-In (Windows Hello for Business)

Attacks & exploits:

• Theft of the post-authentication token (for example the Primary Refresh Token or its cookie) by malware on an unlocked endpoint; a strong login does not protect a stolen session¹⁹.

• Physical bus-sniffing against some discrete TPMs, and timing side-channels against certain implementations.

• Device theft while unlocked; downgrade to a weaker fallback method.

Mitigations:

• Token binding and Continuous Access Evaluation; short token lifetimes.

• EDR on endpoints; BitLocker with secure boot; inactivity lock and biometric/PIN re-prompts.

• Remove phishable fallback paths; monitor new device registrations.

12.12 FIDO2, WebAuthn and Passkeys

Attacks & exploits:

• Post-authentication session/token theft (origin binding protects the login, not the session it creates).

• Compromise of the sync account (Apple Account or Google Account) for synced passkeys.

• Account-recovery downgrade to a phishable fallback; loss of the sole authenticator.

Mitigations:

• Session protection and Continuous Access Evaluation; sender-constrained tokens.

• Strong protection and recovery for the passkey sync account; consider device-bound keys for the highest assurance.

• Design recovery to the same assurance as primary authentication; enrol a backup authenticator; use enterprise attestation to admit only approved devices.

Reading this part. Two patterns recur. First, every shared-secret method is ultimately phishable or crackable, and the fix is to move to asymmetric, origin-bound credentials. Second, for the strongest methods the residual risk is no longer the login but the token, the recovery path, and the trust placed in the identity provider — which is the subject of the next part.

Part 13: The Limits of Passwordless and Hardware-Backed Identity

Hardware-backed, phishing-resistant authentication is a genuine advance and should be the destination for most organisations. But it is not a finish line, and presenting it as one does a disservice. This part states the residual weaknesses plainly.

• Post-authentication token theft. The strongest possible login still ends by issuing a session token. If that token can be stolen from the endpoint or from where it is later stored, the attacker inherits the session regardless of how it was obtained — exactly what happened to a FIDO2-protected account in the Okta 2023 case¹⁹. Token binding, proof-of-possession, short lifetimes, and continuous access evaluation reduce but do not eliminate this.

• Malware on an unlocked endpoint. The TPM protects the key, not the running session. Malware on a device the user has already unlocked can ride the authenticated context, request token operations, scrape cookies, or act as the user. Hardware-backed identity assumes a reasonably healthy endpoint; endpoint security remains essential.

• Device theft while authenticated. An attacker who steals an unlocked or recently used device may have a window of access. Biometric or PIN re-prompts, inactivity locks, and the TPM’s anti-hammering limit this, but the risk is real for high-value targets.

• Synced passkey and cloud-account risk. Synced passkeys trade some hardware-binding for usability: the credentials live in a provider’s end-to-end-encrypted keychain. This makes the sync account (an Apple Account or Google Account) a high-value target, and shifts part of the security boundary to that account’s protection and recovery¹. Device-bound passkeys avoid this at the cost of convenience.

• Account recovery as the weakest link. If losing a device forces a fallback to email links, SMS codes, or security questions, attackers simply target the fallback. A phishing-resistant primary method paired with a phishable recovery method is only as strong as the recovery method. Recovery must be designed to the same standard as primary authentication.

• Management-plane and MDM compromise. If an attacker compromises the mobile-device-management or identity-platform administration plane, they can enrol devices, alter conditional-access policy, or reset authenticators. The control plane that governs hardware-backed identity becomes the target.

• Identity-provider concentration risk. Federation concentrates trust. A compromise of the identity provider — or of its signing keys, as in Golden SAML — cascades to every relying party²⁰. The convenience of single sign-on is also a single point of catastrophic failure, which is why the integrity and monitoring of the IdP matter as much as any authenticator.

• TPM and biometric edge cases. Researchers have demonstrated bus-sniffing attacks against some discrete TPMs and timing side-channels against certain implementations; these generally require physical access or specific conditions but are not merely theoretical. Biometric sensors face presentation (“spoofing”) attacks, mitigated but not wholly eliminated by liveness detection. Hardware roots of trust raise the cost of attack dramatically; they do not reduce it to zero.

The honest summary. Hardware-backed, phishing-resistant authentication closes the credential-theft and phishing chapters that dominated the first three decades. In doing so it moves the contest to three new fronts: the session token after login, the recovery and enrolment processes around login, and the identity provider that everything trusts. A mature programme treats those three as first-class problems rather than assuming passwordless has solved security.

Part 14: Cross-Platform Hardware-Backed Identity

The principles in Part 8 are not Windows-specific. Every major platform now offers a hardware root of trust and origin-bound credentials; the differences are in implementation and management.

14.1 Windows

Windows uses the TPM, surfaced through Windows Hello for Business (Part 8) and as a WebAuthn platform authenticator. Keys are TPM-protected and non-exportable; the PIN or biometric unlocks their use locally¹⁶.

14.2 Apple

Apple devices generate and store keys in the Secure Enclave, a dedicated coprocessor isolated from the main processor. Touch ID or Face ID gates the use of those keys locally, exactly as a PIN gates a TPM. Apple’s passkeys are stored in the iCloud Keychain and synced end-to-end-encrypted across the user’s Apple devices; this is the synced-passkey model, with the convenience and the account-dependence discussed in Part 13. Device-bound keys (for example, those backing managed-device identity) remain in the Secure Enclave.

14.3 Android

Android provides a hardware-backed Keystore in the processor’s trusted execution environment, and StrongBox, which places keys in a dedicated secure element (such as a Titan-class chip) for stronger isolation. Android supports key attestation so a relying party can verify that a key is hardware-protected, and it syncs passkeys through the platform password manager. The mechanics mirror the TPM model¹⁴.

14.4 Linux and SSH

Linux centralises authentication through PAM (Pluggable Authentication Modules), historically backing password, LDAP, and Kerberos logins and now FIDO2 and security-key modules. Separately, SSH — the backbone of server and network-device administration — moved from passwords to key-based authentication, and then to SSH certificates: a certificate authority signs short-lived, identity-bound certificates, giving the expiry, central control, and revocation that bare keys lack. SSH private keys can themselves be held in a TPM or hardware key. This is the same trajectory — from shared secret, to long-lived key, to centrally governed, hardware-held, expiring credential — seen everywhere else in this document.

14.5 Enterprise Attestation Differences

WebAuthn allows different levels of attestation conveyance — from none, which maximises user privacy, to enterprise attestation, which lets an organisation verify the exact make and model of an authenticator (identified by its AAGUID) before trusting it¹³. Consumer flows typically use no attestation; regulated enterprises often require it to ensure only approved, hardware-backed authenticators are enrolled. This is a key planning decision when standardising authenticators across a fleet.

Part 15: Operational Guidance for Migration

Moving an organisation from passwords to hardware-backed, phishing-resistant, federated identity is a multi-year programme, not a switch. The following consolidates the practical considerations most often underestimated.

15.1 Sequencing

• Establish federation and SSO first. Consolidate applications behind one identity provider so that strengthening one authentication point protects many services.

• Raise the floor, then the ceiling. Eliminate the weakest factors (SMS, email OTP) and deploy any MFA broadly before perfecting phishing-resistant methods for high-value populations.

• Target phishing-resistant methods to risk. Prioritise administrators, finance, and access to crown-jewel systems for FIDO2/passkeys, aligning assurance to the NIST authentication assurance levels¹.

15.2 Legacy Compatibility

Legacy protocols are the soft underbelly of any rollout. Basic authentication, legacy mail protocols, and applications that cannot speak modern federation will bypass conditional access and phishing-resistant policy unless explicitly blocked or fronted by a proxy. Inventory and retire or isolate them; attackers specifically seek the path that does not enforce the new controls.

15.3 Break-Glass and Resilience

Maintain a small number of emergency-access (“break-glass”) accounts that are excluded from conditional-access policies that could lock everyone out, protected by the strongest available credentials, stored securely offline, and monitored for any use. Plan explicitly for identity-provider outage, since concentrating authentication also concentrates availability risk.

15.4 Hybrid Identity Pitfalls

Organisations spanning on-premises Active Directory and a cloud identity provider must protect the synchronisation and federation components with particular care. The SAML token-signing key and the federation servers are, as Golden SAML demonstrated, capable of undermining the entire estate²⁰. Protect signing keys in hardware, rotate them, and monitor for forged-token indicators.

15.5 Certificate and Key Lifecycle

Certificate-trust deployments and SSH-certificate schemes introduce a lifecycle that must be managed: issuance, renewal, expiry, and revocation. Unmanaged expiry causes outages; unmanaged revocation causes lingering access. Automate the lifecycle and alert on impending expiry.

15.6 Attestation and Enrolment Failures

Plan for the real-world friction of hardware-backed identity: devices without a functioning TPM, attestation failures, users without enrolled biometrics, and shared or kiosk devices. Define fallbacks that do not quietly reintroduce a phishable path, and govern device enrolment so that registering a new authenticator is itself a strongly verified event (recalling Part 11’s help-desk and registration attacks).

15.7 Identity Governance and Monitoring

Authentication is only half of identity. Joiner-mover-leaver processes, least privilege, access reviews, and prompt deprovisioning determine how much an attacker gains from any single compromise. Instrument the identity provider for the techniques in Part 11 — impossible travel, new-device registration, anomalous token use, mass consent grants, and session anomalies¹⁷ — and align the whole programme to a Zero Trust model of per-request, context-aware decisions².

Part 16: Comparison of Methods

The table summarises how the methods compare on the properties that matter most: the kind of secret involved, where it lives, whether anything reusable crosses the network, and whether the method resists phishing.

One caveat qualifies the last two rows. “Phishing-resistant” describes the login ceremony, not the session that follows it. As Parts 11–13 establish, a stolen post-authentication token can still grant access regardless of how strong the original login was — which is why session protection, monitoring, and identity-provider integrity belong in any honest comparison.

Conclusion

Three decades of authentication can be read as a single sustained effort to stop relying on a secret that humans must know and servers must store. The local password on a 1990s router and the PIN on a modern laptop look superficially similar — both are short values a person types — but they are opposites in every way that matters. The router’s password was the credential: stored, transmitted, reusable, and stealable. The laptop’s PIN authenticates nothing remotely; it merely unlocks a hardware-held key that proves identity by signing a fresh challenge, and that key never leaves the chip.

That shift is real and worth making. But it relocates the problem rather than ending it. As login became phishing-resistant, attackers turned to the session tokens login produces, to the recovery and help-desk processes that can replace an authenticator, and to the identity provider whose signature every service trusts — as Uber, Okta, and the SolarWinds campaign each demonstrated in different ways. The credential-theft era is closing; the session-theft and trust-abuse era is open.

For organisations, the practical path is clear: move authentication onto asymmetric, hardware-backed, phishing-resistant foundations and federate that strong proof across services; then treat session protection, recovery design, device governance, and identity-provider integrity as equally first-class. The standards to do this exist and are current — NIST’s 2025 guidelines now make phishing-resistant authentication the baseline¹, and the W3C, FIDO Alliance, and platform vendors have made the technology deployable today. What remains is the discipline to retire the shared secret without imagining the work is finished.

About CyberCQR

CyberCQR is a specialist cybersecurity consultancy providing executive and board-level advisory on identity security, Zero Trust architecture, and the transition to modern, passwordless authentication.

www.cybercqr.com | contact@cybercqr.com

© 2026 CyberCQR. Technical reference — may be shared with attribution. Version 3.0.

Glossary

Key terms and acronyms used in this document.

AAA — Authentication, Authorisation, and Accounting — the three functions central network protocols provide.

AAGUID — Authenticator Attestation GUID; identifies the make and model of a FIDO2 authenticator.

ABAC — Attribute-Based Access Control; access decided by attributes such as department or risk level.

Active Directory (AD) — Microsoft’s directory and identity platform, combining LDAP, Kerberos, and NTLM.

AiTM — Adversary-in-the-Middle; a relay/proxy phishing attack that captures credentials and session cookies in real time.

Anti-hammering — A TPM or authenticator lockout that escalates after repeated incorrect PIN attempts.

Attestation — Cryptographic proof that a key resides in genuine hardware, and which authenticator model produced it.

CAE — Continuous Access Evaluation; re-checking and revoking access mid-session when risk changes.

CTAP — Client to Authenticator Protocol; the FIDO2 protocol between a client device and an authenticator.

DPoP — Demonstrating Proof-of-Possession; binds a token to a key so a stolen token alone cannot be replayed.

EAP — Extensible Authentication Protocol; an authentication framework used with 802.1X and RADIUS.

EDR — Endpoint Detection and Response.

Federation — One identity provider vouching for a user’s identity to many relying parties that trust it.

FIDO2 — The open standard combining WebAuthn and CTAP for phishing-resistant, public-key authentication.

fTPM — Firmware TPM; a TPM implemented within the main processor’s secure execution environment.

Golden SAML — Forging SAML tokens with a stolen identity-provider signing certificate, bypassing authentication and MFA.

Golden Ticket — Forging a Kerberos ticket-granting ticket using the stolen krbtgt key.

HOTP — HMAC-based One-Time Password; a counter-based one-time code (RFC 4226).

HSM — Hardware Security Module; tamper-resistant hardware for generating and protecting keys.

IdP — Identity Provider; the authority that authenticates users and issues tokens or assertions.

IDAM / IAM — Identity and Access Management.

JWT — JSON Web Token; a signed token format used by OpenID Connect and OAuth.

Kerberoasting — Requesting service tickets to crack service-account passwords offline.

Kerberos — A ticket-based authentication protocol using a central Key Distribution Centre (RFC 4120).

krbtgt — The Active Directory account whose key signs Kerberos tickets; its compromise enables Golden Tickets.

LDAP — Lightweight Directory Access Protocol; querying a directory of identities and attributes (RFC 4511).

MDM — Mobile Device Management.

MFA — Multi-Factor Authentication.

NTLM — A legacy Microsoft challenge-response authentication protocol.

OAuth 2.0 — A delegated-authorisation framework that issues scoped access tokens (RFC 6749).

OIDC — OpenID Connect; an identity layer built on OAuth 2.0.

OTP — One-Time Password.

Pass-the-cookie — Replaying a stolen post-authentication session cookie to impersonate a user.

Passkey — A user-friendly FIDO2 credential, either device-bound or synced across a user’s devices.

PKCE — Proof Key for Code Exchange; protects OAuth authorization codes from interception.

PKI — Public Key Infrastructure; certificates binding public keys to identities, issued by a certificate authority.

PRT — Primary Refresh Token; a device-bound token in Microsoft Entra used for single sign-on.

RADIUS — Remote Authentication Dial-In User Service; AAA over UDP, common for network access (RFC 2865).

RadSec — RADIUS transported over TLS or DTLS for confidentiality and integrity.

RBAC — Role-Based Access Control.

Relying Party (RP) — A service that trusts an identity provider’s assertions or tokens.

SAML — Security Assertion Markup Language; an XML-based federation standard (SAML 2.0, OASIS).

SASE — Secure Access Service Edge.

Secure Enclave — Apple’s dedicated security coprocessor that generates and holds keys.

SSO — Single Sign-On.

StrongBox — Android’s dedicated, secure-element-backed keystore.

TACACS+ — Terminal Access Controller Access-Control System Plus; AAA over TCP, common for device administration (RFC 8907).

TGT — Ticket-Granting Ticket, issued by the Kerberos Key Distribution Centre.

TLS — Transport Layer Security.

TOTP — Time-based One-Time Password (RFC 6238).

TPM — Trusted Platform Module; a tamper-resistant chip providing a hardware root of trust (TPM 2.0).

WebAuthn — The W3C web-authentication API for creating and using public-key credentials.

Zero Trust — A security model of “never trust, always verify,” making per-request, context-aware access decisions.

Further Reading

Readers seeking depth beyond this document should start with the primary standards in the References section — in particular the NIST SP 800-63 suite and SP 800-207 for assurance levels and Zero Trust, the W3C WebAuthn specification and FIDO Alliance materials for passwordless authentication, and the Trusted Computing Group TPM 2.0 library for the hardware root of trust. For attacker techniques, the MITRE ATT&CK knowledge base and the cited CISA advisories provide structured, continually updated detail.

References

Standards, specifications, and primary reporting underpinning this document. Citation numbers correspond to the superscript markers in the text.

1. NIST SP 800-63-4 / 800-63B-4, Digital Identity Guidelines. National Institute of Standards and Technology, August 2025. Establishes phishing-resistant authentication and syncable/device-bound passkeys within the AAL2 and AAL3 requirements; supersedes SP 800-63-3. https://pages.nist.gov/800-63-4/

2. NIST SP 800-207, Zero Trust Architecture. National Institute of Standards and Technology, August 2020. Defines the tenets of Zero Trust and per-request access decisions. https://csrc.nist.gov/pubs/sp/800/207/final

3. RFC 2865, Remote Authentication Dial In User Service (RADIUS). IETF, June 2000. https://www.rfc-editor.org/rfc/rfc2865

4. RFC 8907, The TACACS+ Protocol. IETF, September 2020. Documents the protocol originally developed by Cisco. https://www.rfc-editor.org/rfc/rfc8907

5. RFC 4120, The Kerberos Network Authentication Service (V5). IETF, July 2005. https://www.rfc-editor.org/rfc/rfc4120

6. RFC 4511, Lightweight Directory Access Protocol (LDAP): The Protocol. IETF, June 2006. https://www.rfc-editor.org/rfc/rfc4511

7. RFC 4226, HOTP: An HMAC-Based One-Time Password Algorithm. IETF, December 2005. https://www.rfc-editor.org/rfc/rfc4226

8. RFC 6238, TOTP: Time-Based One-Time Password Algorithm. IETF, May 2011. https://www.rfc-editor.org/rfc/rfc6238

9. RFC 6749, The OAuth 2.0 Authorization Framework. IETF, October 2012. https://www.rfc-editor.org/rfc/rfc6749

10. OpenID Connect Core 1.0. OpenID Foundation, 2014 (with errata). https://openid.net/specs/openid-connect-core-1_0.html

11. Assertions and Protocols for SAML 2.0 (OASIS Standard). OASIS, March 2005. https://docs.oasis-open.org/security/saml/v2.0/

12. IEEE Std 802.1X-2020, Port-Based Network Access Control. IEEE, 2020. https://standards.ieee.org/ieee/802.1X/7345/

13. Web Authentication: An API for Accessing Public Key Credentials, Level 2. W3C Recommendation, 8 April 2021. (Level 3 reached Candidate Recommendation in January 2026.) https://www.w3.org/TR/webauthn-2/

14. FIDO2: WebAuthn and CTAP (Client to Authenticator Protocol). FIDO Alliance specifications. https://fidoalliance.org/specifications/

15. TPM 2.0 Library Specification (also ISO/IEC 11889). Trusted Computing Group. https://trustedcomputinggroup.org/resource/tpm-library-specification/

16. Windows Hello for Business documentation. Microsoft Learn. Covers key-trust, certificate-trust, and cloud-trust deployment models and the TPM-protected key architecture. https://learn.microsoft.com/windows/security/identity-protection/hello-for-business/

17. MITRE ATT&CK Knowledge Base. The MITRE Corporation. Techniques referenced include T1539 (Steal Web Session Cookie) and T1550.004 (Use Alternate Authentication Material: Web Session Cookie). https://attack.mitre.org/

18. Uber Security Update (September 2022 incident). Uber, 2022. MFA-fatigue compromise of a contractor account attributed to Lapsus$. https://www.uber.com/newsroom/security-update/

19. Okta Customer Support System Breach (October 2023). Reported by BleepingComputer and disclosed by Okta, BeyondTrust, 1Password, and Cloudflare. Session tokens in HAR files used for session hijacking. https://www.bleepingcomputer.com/news/security/okta-breach-134-customers-exposed-in-october-support-system-hack/

20. CISA Alert AA20-352A: Advanced Persistent Threat Compromise of Government and Private Sector Organisations (SolarWinds / Golden SAML). Cybersecurity and Infrastructure Security Agency, December 2020. https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a

21. The Full Story of the Stunning RSA Hack (RSA SecurID, 2011). WIRED, 2021 retrospective by Andy Greenberg. https://www.wired.com/story/the-full-story-of-the-stunning-rsa-hack-can-finally-be-told/

22. CISA Advisory AA23-320A: Scattered Spider. Cybersecurity and Infrastructure Security Agency, November 2023. Help-desk social engineering and MFA reset/registration abuse. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a

23. CVE-2024-3596 (“Blast-RADIUS”), RADIUS Protocol Forgery. Disclosed July 2024. An on-path attacker can forge RADIUS responses via an MD5 chosen-prefix collision against the Response Authenticator; mitigated by the Message-Authenticator attribute and RADIUS-over-TLS (RadSec). https://www.blastradius.fail/