Authentication & Access Control

Identity and the Three Factors

Authentication factors fall into three categories, and every credential you have ever used belongs to one of them. Some frameworks add a fourth and fifth category, somewhere you are (location or network context) and something you do (behavioral patterns like typing cadence), but the original three cover the overwhelming majority of real systems.

Why the Factors Fail Independently

The reason this categorization matters is that each factor fails independently, for different reasons. A password can be guessed, phished, or leaked in a breach dump. A hardware token can be lost or stolen, but a remote attacker sitting in another country cannot casually acquire it.

A fingerprint cannot be reused across a thousand other sites the way a reused password can. When an attacker defeats one factor, the other factors are not automatically compromised too, because the attack surface for each one is different. That independence is the entire security value of combining them.

Why "Two-Factor" Gets Misused

This is also why the phrase "two-factor authentication" gets misused constantly. Requiring a password plus a security question is not two-factor authentication, because both are something you know. An attacker who phishes your password with a fake login page can usually phish or guess the security question answer in the same session.

Real multi-factor authentication requires two DIFFERENT categories: something you know paired with something you have, or something you have paired with something you are. The category boundary is what forces an attacker to pull off two structurally different attacks instead of one attack repeated twice.

Applying This in a SOC Context

In a SOC context this distinction shows up constantly when reviewing authentication logs or vendor claims. A login flow that asks for a password and then a one-time code sent to email is weaker than it sounds, because if the attacker already has the password from a breach, email is frequently compromised through the same credential-reuse chain.

A password plus a push notification to a registered device is genuinely stronger, because compromising the device requires a separate attack path entirely. When you are assessing an authentication control, the first question to ask is not "how many steps" but "how many genuinely independent categories."

MFA Mechanics: TOTP, Push, and Passkeys

TOTP: Codes From a Shared Secret and the Clock

Time-based One-Time Password (TOTP) is the mechanism behind most authenticator apps: Google Authenticator, Microsoft Authenticator, Authy, and the codes generated by hardware tokens like a YubiKey in OTP mode. When you scan a QR code to set up MFA, the server and your app agree on a shared secret, a random string encoded in the QR data. From that point on, both sides independently compute a code by feeding the shared secret and the current time, rounded down to a fixed step (usually 30 seconds), into an HMAC hash function, then truncating the output to a short numeric code.

Because both sides start from the same secret and the same clock, they arrive at the same code without ever transmitting it over the network during generation. This is why TOTP still works when your phone is offline: it needs the secret and a synced clock, nothing else.

SMS OTP: Weak by Delivery Channel, Not by Code

SMS-based one-time codes are weaker than TOTP for reasons that have nothing to do with the code itself. The weakness is the delivery channel. SIM-swapping attacks let an adversary port your phone number to a device they control by social-engineering a carrier's support desk, after which every SMS code goes straight to them.

SS7 protocol weaknesses in the telecom backbone allow interception of SMS traffic without touching the victim's phone at all. NIST deprecated SMS as an acceptable out-of-band authenticator for this reason years ago, though it remains common because it requires no app install and works on any phone.

Push-Based MFA and Push-Bombing

Push-based MFA sends an approve-or-deny prompt to a registered device instead of a code to type. It is convenient, but that convenience is exactly what push-bombing (also called MFA fatigue) attacks exploit. An attacker who already has a valid password triggers repeated push notifications, sometimes dozens in a row, hoping the victim eventually taps "approve" just to make the notifications stop, or mistakes it for a legitimate login they forgot about.

This technique was used in several well-documented enterprise breaches where the initial password was obtained through an unrelated credential leak and the MFA prompt was the last barrier. Number-matching, where the user must type a code shown on the login screen into the push prompt, was introduced specifically to defeat mindless-tap approval, because it forces the user to look at the login context before approving.

Passkeys: Public-Key Cryptography, No Shared Secret

Passkeys, built on the FIDO2/WebAuthn standard, are structurally different from both TOTP and push. Instead of a shared secret that both sides need to protect, a passkey uses public-key cryptography: your device generates a key pair during registration, keeps the private key locked inside a secure enclave or TPM, and gives the website only the public key.

During login, the site sends a challenge, your device signs it with the private key, and the site verifies the signature. The private key never leaves your device and is never typed anywhere, which removes phishing as a viable attack entirely, since there is no secret for a fake login page to capture.

The other property that makes passkeys phishing-resistant is origin binding: the browser cryptographically ties the credential to the exact domain it was registered on, so a lookalike phishing domain cannot even request a valid signature, let alone forge one.

Authorization Models: RBAC, ABAC, DAC, MAC

Once identity is established, authorization decides what that identity can do, and different systems make that decision using fundamentally different logic. The four models below cover almost every access control system you will encounter.

RBAC: Role-Based Access Control

Role-Based Access Control (RBAC) assigns permissions to roles rather than to individual users, and users get permissions by being assigned to one or more roles. A "Help Desk Tier 1" role might get permission to reset passwords and view ticket queues but not to modify firewall rules.

This is the model behind most enterprise applications, from Active Directory groups to SaaS admin consoles, because it scales cleanly: onboarding a new help desk employee means adding them to one role instead of hand-configuring dozens of individual permissions.

ABAC: Attribute-Based Access Control

Attribute-Based Access Control (ABAC) makes decisions dynamically, evaluating attributes of the user, the resource, and the environment at the moment of the request rather than relying on a fixed role assignment. A policy might read: allow access to this S3 bucket if the user's department attribute is "finance," the request originates from a corporate IP range, and the time is within business hours.

This is the model behind cloud IAM policy engines like AWS IAM conditions or Azure Conditional Access, because cloud environments need decisions that account for context (device posture, location, resource sensitivity tags) that a static role can't express on its own.

DAC: Discretionary Access Control

Discretionary Access Control (DAC) lets the owner of a resource decide who else gets access to it. When you set sharing permissions on a Google Doc or change file permissions on a Windows share you own, you are exercising DAC.

It is flexible and intuitive for end users, which is also its weakness: permissions sprawl because there is no central policy enforcing consistency, and an owner can grant access far more broadly than an organization would want, often without anyone else reviewing the decision.

MAC: Mandatory Access Control

Mandatory Access Control (MAC) removes that discretion entirely. Access decisions are made by a central authority based on fixed classification labels, and neither the resource owner nor the user can override them. A document labeled "Secret" cannot be shared with a user holding only a "Confidential" clearance, no matter what the document owner wants.

This is the model used in classified government and military systems, and in commercial systems like SELinux where the kernel enforces label-based policy regardless of file ownership. MAC trades flexibility for guaranteed policy enforcement, which is exactly the tradeoff a classified environment needs.

Most enterprises run RBAC for internal applications, layer ABAC on top for cloud resources where context matters, tolerate a degree of DAC for day-to-day file sharing, and reserve MAC for the rare environment where compliance or classification requirements demand it. Knowing which model you are looking at during an access review changes what question you ask, as the table above shows.

Least Privilege and Privilege Creep

The principle of least privilege states that an identity, whether human or service account, should hold only the permissions strictly required to perform its current job, and nothing more. It sounds obvious stated that way, but almost no organization actually maintains it over time, because permissions accumulate far more easily than they get removed.

Granting access is a one-click action that unblocks someone immediately. Revoking access is a low-priority cleanup task that nobody owns, so it gets deferred indefinitely.

How Privilege Creep Happens

Privilege creep is the slow accumulation of unnecessary access that results from that asymmetry. It happens in a few predictable ways.

• A role transfer with no deprovisioning step. An employee moves from the finance team to the marketing team and keeps their old finance system access because nobody triggered a deprovisioning step during the transfer.
• A contractor's temporary access outliving the project. A contractor gets temporary elevated access to finish a migration project and the access is never pulled once the project ends.
• An emergency grant that quietly becomes permanent. An analyst is granted admin rights "just for this one incident" during an emergency and the grant quietly becomes permanent because removing it would require someone to notice it and act on it.

Why It's Dangerous

Privilege creep is one of the single most common findings in real access audits, and it is dangerous for a specific reason beyond general hygiene: it expands the blast radius of every future compromise. If an attacker phishes a marketing employee's credentials and that account still holds finance-system access from two roles ago, the attacker inherits access far beyond what the compromised job function should ever have needed.

Least privilege is not just about preventing insider misuse; it directly limits what any single compromised account can do once an attacker is inside.

Fixing It: Process, Not a One-Time Cleanup

Fixing privilege creep requires a process, not a one-time cleanup.

• Regular access reviews (often called access certifications or attestations) force managers to explicitly re-confirm that each of their team's permissions is still needed, on a quarterly or semi-annual cycle.
• Just-in-time access, where elevated permissions are granted for a defined window and expire automatically, replaces the pattern of permanent "just for now" grants.

Both approaches shift the default from "access persists until someone notices" to "access expires unless someone actively renews it," which is the opposite failure mode and a much safer one to be stuck in.

Zero Trust: Never Trust, Always Verify

The traditional perimeter security model treated the network boundary as the trust boundary: anything inside the corporate firewall was implicitly trusted, and security effort concentrated on keeping attackers out at the edge. Once an attacker (or a rogue insider, or a compromised laptop) got past that edge, lateral movement inside the network was often trivially easy, because internal traffic was assumed safe by default.

This model made sense when most work happened on-premises with a well-defined network edge. It stopped making sense once cloud services, remote work, and mobile devices dissolved any single defensible perimeter.

Zero Trust replaces "trusted inside, untrusted outside" with a single rule: never trust, always verify, regardless of where the request originates. Being on the corporate VPN or inside the office network grants no implicit trust at all. Every request to every resource is authenticated and authorized on its own merits, every time, based on current context rather than network location.

The Three Tenets

• Verify explicitly. Every access decision uses all available signals, identity, device health, location, and behavior pattern, rather than trusting a single network-location check.
• Least privilege access. Every grant is scoped as narrowly as possible and often time-limited, echoing the principle covered above but enforced continuously rather than at initial account setup.
• Assume breach. The architecture is designed as though an attacker is already inside the network, using segmentation, encryption, and continuous monitoring to limit what that attacker can reach and how long they can operate undetected, rather than betting everything on keeping them out in the first place.

A Concrete Scenario

Under the old perimeter model, an employee who connected to the office Wi-Fi or corporate VPN could reach an internal HR application with little further scrutiny, because they were "inside." Under Zero Trust, that same employee reaching the same application triggers a full evaluation regardless of network location:

• Is this a recognized, healthy, compliant device?
• Does this identity's current role justify access to this specific application?
• Is the request pattern consistent with how this user normally behaves?

If the device fails a compliance check, say it is missing a required security patch, access can be denied or stepped up to an additional verification challenge even though the user is sitting in the building on the corporate network. The network is no longer doing any of the trust decision on its own.

Common Authentication Attacks

Credential Stuffing

Credential stuffing takes username-and-password pairs leaked from one breach and replays them against other services, betting on password reuse. Because the attacker already has valid-looking credentials, the traffic pattern is high-volume automated logins against many different accounts, each attempt using a credential pair harvested elsewhere.

It succeeds purely because people reuse passwords across services, and it fails immediately against any account protected by real multi-factor authentication, since the attacker has a password but not the second factor.

Password Spraying

Password spraying flips the usual brute-force pattern. Instead of trying many passwords against one account (which triggers lockout thresholds quickly), it tries one or a few common passwords, "Summer2026!", "Password123", against a large number of accounts, staying under each individual account's lockout threshold while still eventually landing on someone using a weak, common password.

It is slow and low-and-slow by design, which is exactly what makes it evade naive per-account lockout defenses.

MFA Fatigue / Push-Bombing

MFA fatigue, or push-bombing, was already covered in the mechanics section above but deserves listing here as an attack category on its own: an attacker with a valid password sends repeated push approval prompts until the victim taps approve out of annoyance or confusion, effectively social-engineering the second factor rather than technically defeating it.

Session and Token Hijacking

Session and token hijacking skips the login process entirely by stealing an already-authenticated session, through a stolen session cookie, a leaked bearer token, or an adversary-in-the-middle phishing proxy that relays a live login session in real time and captures the resulting session token.

This is particularly dangerous against TOTP-protected accounts, because the attacker never needs to defeat the TOTP code at all; they let the real user complete authentication through the proxy and steal the session that authentication produces.

Each of these attacks leaves a distinct fingerprint in authentication logs, which is exactly what makes detection possible even without stopping the initial attempt.