Identity and access

Before a system grants access, it must verify the identity of the party requesting it. This process is authentication. The evidence provided during authentication falls into three categories, known as factors.

Something you know covers knowledge factors: passwords, PINs (Personal Identification Numbers), and security questions. These are the most widely used but also the most vulnerable, because knowledge can be stolen, guessed, or phished.

Something you have covers possession factors: a physical security key, a smartphone running an authenticator app, or a smart card. Possession factors are harder to steal remotely because the attacker needs physical access or malware on the device.

Something you are covers inherence factors: fingerprints, facial recognition, retina scans. Biometric factors are convenient and difficult to share deliberately, but they cannot be changed if compromised and may have false acceptance or rejection rates that create usability problems.

Multi-factor authentication combines factors from at least two different categories. The key word is different categories: two passwords are not multi-factor. A password and a code from an authenticator app qualify, because one is something you know and the other is something you have.

Most organisations still enforce the password policy that the current standard now prohibits. NIST SP 800-63B-4, finalised in 2025, rewrote the rules on the evidence of what actually keeps accounts safe, and the change is worth stating plainly because it reverses two decades of habit.

Length beats complexity. A long passphrase is far harder to crack than a short string of mixed symbols, and it is easier to remember, so the standard now tells verifiers to require a minimum length and to allow much longer secrets. Where a password is the only factor, aim for at least 15 characters. Composition rules, the familiar demand for an uppercase letter, a digit and a symbol, are now a SHALL NOT: the standard says verifiers shall not impose them, because they push people towards predictable substitutions such as Password1! without adding real strength.

Forced periodic rotation is also gone. Requiring a new password every ninety days made people iterate a weak base, so the standard says do not force routine expiry. Change a password when there is evidence it has been compromised, not on a calendar.

What replaces the old rules is screening and tooling. Check every new password against a blocklist of known-breached and common values and reject a match. Encourage a password manager so that each account can hold a long, unique, random secret nobody has to remember. Better still, move the account off passwords entirely, which is where the next section goes.

The right question about multi-factor authentication is not whether an account has it, but which tier it uses, because the tiers are far apart in strength. SMS one-time codes sit at the bottom: they are better than a password alone, but the code travels over the telephone network, so a SIM-swap (persuading a carrier to move a victim's number to an attacker-controlled SIM) or an interception of the network signalling can capture it. An authenticator app generating a time-based code sits above SMS, because the code never leaves the device. A push approval sits alongside it. At the top sit phishing-resistant credentials: a FIDO2 security key or a passkey, which use public-key cryptography bound to the real website domain.

The reason the tiers matter is that the codes and push approvals are no longer enough against an industrialised attack. An adversary-in-the-middle kit, sold ready-made under names such as Evilginx, Tycoon 2FA and EvilProxy, does not try to guess the second factor. It relays the genuine login page to the victim in real time. The victim types the password, the real provider issues its one-time code or push, the victim satisfies it, and the real provider hands back a session token, the cookie that proves the login already happened. The proxy steals that token and replays it, so the attacker is signed in without ever needing the password or the code again.

A passkey is the control that breaks this chain, because the credential is bound to the real domain. At the proxy's lookalike origin the browser simply will not release it, so the attack stops at the proxy step. The figure below traces the five steps of the attack and marks where the passkey refuses.

Authentication confirms who a user is. Authorisation determines what that user is allowed to do. Two primary access control models define how authorisation rules are structured.

RBAC (Role-Based Access Control) assigns permissions to roles rather than individual users. A user gains access by being assigned a role. A hospital might define roles such as Nurse, Doctor, Administrator, and Finance. Each role has a defined set of permissions. When a new employee joins, they receive the appropriate role rather than having permissions manually configured. RBAC is operationally straightforward and scales well for large organisations with predictable job functions.

ABAC (Attribute-Based Access Control)makes access decisions based on attributes: the user's department, the data's classification label, the time of day, and the user's location. A policy might state: "Allow access to patient records only if user.department = Clinical AND record.sensitivity = OFFICIAL AND access.time is between 07:00 and 22:00 AND access.location = Hospital." ABAC provides fine-grained control for complex environments but requires careful policy design and is harder to audit.

The principle of least privilege is the rule that both models exist to serve: give each user only the access their current job needs. In practice, access creep is the most common way it fails. Users accumulate permissions as they change roles over time, but permissions are rarely revoked when they are no longer needed. Regular access reviews, typically quarterly for privileged accounts and annually for standard accounts, are the primary control. The process is simple: ask each manager to confirm which permissions each of their direct reports actually needs, and remove those that cannot be justified.

SSO (Single Sign-On) allows a user to authenticate once and access multiple systems without re-entering credentials. Common SSO protocols include SAML 2.0 (Security Assertion Markup Language) and OpenID Connect, which builds on OAuth 2.0. SSO improves usability by reducing password fatigue and improves security by centralising authentication, meaning MFA enforcement can be applied at the identity provider rather than inconsistently across individual applications.

The security trade-off: centralising authentication creates a single high-value target. If the identity provider is compromised, all connected applications are at risk. This is why identity providers (such as Microsoft Entra ID, Okta, or Google Workspace) require the strongest available MFA and receive enhanced monitoring attention.

Sessions are the loose end. The session token that single sign-on issues after a successful login is exactly what an adversary-in-the-middle kit steals, and a stolen token grants access with no further login. That is why session lifetime and binding matter as much as the strength of the login itself: short-lived tokens, re-authentication for sensitive actions, and binding a session to the device or network it started on all shrink the value of a token an attacker manages to lift.