The terms, defined for the person who has to explain them

An attacker gains control of a legitimate account — through a stolen credential, a hijacked session or a bypassed second factor — and acts as its owner. Every action that follows is technically authorized, which is what makes it hard to see.

Microsoft's directory service: the database of users, groups and computers that most organizations authenticate against. Windows logons use Kerberos or NTLM; applications usually query and authenticate against it over LDAP.

Authentication whose demand changes with context and risk — where the request comes from, on what device, at what time, and whether it fits the account's normal behavior. A low-risk sign-in is let through; a risky one is challenged harder or refused.

Microsoft's on-premise federation service, used to provide SAML-based single sign-on from an Active Directory. Widely deployed and still running in many estates, though Microsoft's direction has moved to its cloud identity provider.

The privileged-access platform supplies the target system's credential into the session itself, so the administrator connects without ever seeing, typing or holding the password. The credential never reaches the workstation.

Trying username-and-password pairs leaked from one breach against other services, on the assumption that people reuse passwords. It works because they do.

Planting decoy accounts and credentials that have no legitimate use. Nothing real is meant to touch them, so an interaction points to enumeration or lateral movement — the highest-certainty detection in the set.

Open standards for public-key authentication in which the credential is bound to the website's origin, so a lookalike site cannot use it — the basis of phishing-resistant sign-in. The authenticator is the device itself (Windows Hello, Touch ID) or a hardware security key; a passkey is a FIDO credential that can be synchronized between devices.

A Windows service account type whose password Active Directory rotates automatically. It removes the never-changing password problem for services that can use it — which excludes many appliances, third-party products and legacy applications.

The system that authenticates a user and issues a signed assertion or token to applications, which then trust it instead of checking a password themselves. In SAML terms the applications are service providers.

Detecting and responding to attacks on identities — accounts, credentials, sessions and the directory — rather than on endpoints or the network. It reads authentication behavior and acts on it: a challenge, a forced reset, an isolation.

Privileged rights granted for a bounded window, on request and usually with approval, instead of standing permanently on the account. When the window closes, the rights go with it.

The default authentication protocol inside an Active Directory domain. It is ticket-based: the password itself never crosses the network, which is one reason LDAP simple bind — which does send the password — is the weaker path.

Moving from an initial foothold to other systems using harvested credentials, shared accounts or trust relationships, towards whatever the attacker actually came for. It is quiet, because each step uses access that looks legitimate.

The protocol applications use to query and authenticate against a directory. A simple bind over plain LDAP sends the username and password in clear text; LDAPS wraps it in TLS, and LDAP signing protects the integrity of the exchange.

A component placed between applications and the directory. Because every bind passes through it, it can add a second factor, replace the credential the application holds with one that works nowhere else, and carry a cleartext leg over TLS — without changing the application.

An attack in which someone holding a valid password triggers push prompt after push prompt until the user approves one to make it stop. It defeats the person, not the protocol.

Requiring two or more independent factors to sign in — something you know (a password), something you have (a phone or key), something you are (a fingerprint). A stolen password alone is then not enough.

An identity used by software rather than a person: a service account, an API key, a certificate. It has no phone for a second factor, is rarely rotated, and often holds broad rights — which makes it a category of exposure of its own.

A push-notification variant in which the sign-in screen shows a number the user must type into the app. An approval can no longer be given by reflex, and a prompt the user did not start has nothing to type against.

A framework for delegated authorization: an application obtains a token to act on a user's behalf without holding their password. OpenID Connect builds identity on top of it.

An identity layer on top of OAuth 2.0. The identity provider issues an ID token that tells the application who the user is, in a JSON format modern applications and APIs expect.

Authenticating with a captured NTLM password hash instead of the password itself. It is one reason a privileged password should never be typed on an ordinary workstation, where its hash can be harvested from memory.

Trying a handful of common passwords against many accounts, slowly enough to avoid lockouts. Against an internet-facing login it eventually meets an account that matches.

Signing in without a password at any step — the second factor becomes the only factor. Nothing is typed that can be phished, sprayed or reused.

Controlling how privileged accounts are used: vaulting their credentials, brokering and recording their sessions, and constraining what can be done inside them.

Gaining rights beyond those granted — a user session becoming an administrative one through a UAC prompt, a sudo, or an exploited weakness. It is the step inside a session most worth challenging.

Remote administrative access that reaches specific systems rather than the network, is authorized on every session, and is recorded — as opposed to a VPN, which connects the device to the network and stops there.

The authentication protocol built into almost every firewall, VPN concentrator and network device. The device sends the credential to a RADIUS server and acts on the answer — which is why a second factor can be added to these devices without installing anything on them.

The XML-based federation standard most enterprise applications use for single sign-on. The identity provider issues a signed assertion; the service provider verifies the signature and signs the user in. Supports sign-in started from either side, and single logout.

An account used by an application or service rather than a person — to bind to the directory, connect to a database, run a scheduled task. Its password is typically set at installation and never changed.

In federation, the application that relies on an identity provider to authenticate its users instead of keeping its own passwords. Also called a relying party.

Capturing a privileged session as video and as a searchable command transcript, so an audit can answer what was done rather than only that a connection happened.

One authentication that grants access to many applications, each federated to a single identity provider. It removes the per-application password and makes strong authentication practical, because it only has to be done once.

Time-based one-time password (RFC 6238): a code derived from a shared secret and the current time, generated by an authenticator app. It needs no network, which is what makes it usable at an offline logon screen.

Learning what normal looks like for each account and entity, then flagging deviations from that baseline — rather than from a company-wide average nobody actually matches.

A RADIUS attribute carrying data defined by a particular vendor — most usefully the group or role a firewall should place the user in, so the device's own policy keeps working after MFA is added.

A credential that exists only inside the proxy or platform and has no counterpart in the directory. The application holds it instead of the real password; captured anywhere else, it authenticates nothing.

No access is trusted because of where it comes from — inside the network, over a tunnel, from a device that connected earlier. Each session is authorized on its own, at the application layer, and only the authorized targets are reachable.