It’s Already When. — RTFM

Logging Without Anyone Reading the Logs

2026-07-15T00:00:00+00:00

Every organization logs. Almost none of them read the logs. This is the oldest open secret in the industry: a SIEM humming in the corner, ingesting a few terabytes a day, generating dashboards nobody opens, firing alerts nobody triages, and satisfying an auditor who checked a box that said “audit logging: enabled.” The comforting fiction is that collection equals visibility. It doesn’t. Collection is storage. Detection is work. And the distance between the two is measured in the number of days an attacker gets to operate before anyone notices, which industry data has kept pinned in the triple digits for the better part of a decade.

The Standard

CIS Critical Security Control 8, Audit Log Management, exists precisely because “we have logs” and “we can detect anything” are unrelated claims. The control breaks into eight safeguards, and it is worth reading them in order because the order is the point.

It starts with 8.1, establishing an audit log management process, and 8.2, collecting audit logs. Fine, table stakes. But 8.3 requires you to ensure adequate audit log storage, because logs that roll over in three days are logs you can’t investigate an incident with. 8.4 mandates time synchronization, because correlation across sources is impossible when your firewall, your domain controller, and your web tier disagree about what time it is. 8.5 pushes for detailed audit logging, capturing source, destination, timestamp, user, and event outcome, not just “something happened.” 8.6 and 8.7 extend collection to DNS and URL/command-line activity. And 8.9 through 8.11 get to the part everyone skips: centralize the logs, retain them for a defined period (CIS suggests a minimum of 90 days, ideally longer), and conduct reviews.

Read that last one again. The control does not say “collect logs.” It says review them. The entire framework is constructed to funnel you toward the act of looking. Most implementations stop at 8.2 and declare victory.

Where It Breaks Down

The failures are specific and depressingly consistent.

Logging the wrong things, verbosely. Teams turn on everything the vendor offers and then drown. A domain controller with full Kerberos and NTLM auditing enabled but no tuning will bury a golden-ticket anomaly under a million routine 4624 and 4634 logon events. Windows Event ID 4688 (process creation) is enormously valuable, but only if you also enabled the command-line auditing GPO, which is off by default. Most environments log that a process started and never capture what it was invoked with, which is the one field that turns “powershell.exe ran” into “powershell.exe ran a base64-encoded download cradle.”

The endpoints that never talk. Domain controllers ship logs. The Linux jump host someone stood up in 2019 does not. Cloud control planes are their own dark continent: CloudTrail exists, but management events and data events are separately configured and separately billed, so data events (the S3 object-level reads that actually reveal exfiltration) are frequently disabled to save money. Kubernetes audit logging is off unless you explicitly wrote an audit policy and wired it into the API server flags. Every one of these gaps is a place where an attacker operates with zero telemetry.

Ingestion without parsing. A log that arrives as an unparsed blob is a log that cannot be queried, correlated, or alerted on. Syslog dumped into an index with no field extraction is a haystack with no magnet. If your user, src_ip, and action fields aren’t normalized to a schema (ECS, OCSF, whatever you’ve chosen), then a query for “all failed authentications by this account across all sources” returns nothing useful, and nobody writes the detection because writing it is miserable.

Alerts with no owner and no triage. The SIEM ships with a thousand correlation rules enabled out of the box. They fire constantly. Within a month the analysts have muted the noisy ones, and within a quarter they’ve stopped looking at the channel entirely. This is alert fatigue, and it is not a personal failing; it is the predictable outcome of deploying detection content nobody tuned against a baseline nobody established.

Retention that quietly lies. Someone configured 90 days of hot retention, then the ingestion volume tripled, the storage tier filled, and the index started aging out at eleven days. Nobody noticed, because nobody was querying anything older than yesterday. The 90-day number still lives in the compliance document.

No time discipline. NTP is “probably fine.” Then an incident happens, you pull logs from four systems, and their timestamps span a nine-minute spread with two different time zones and one host stuck in local time with no offset recorded. Correlation collapses. This is Safeguard 8.4, ignored, and it poisons everything downstream.

Doing It Right

Start from the question, not the source. Detection engineering means deciding what you want to catch and then working backward to the telemetry that would reveal it. Map your desired detections to a framework like MITRE ATT&CK, identify the data sources each technique requires, and only then decide what to collect. This inverts the usual order and immediately tells you that you don’t need debug-level logs from everything; you need specific, high-fidelity events from the right places.

Fix the plumbing before the analytics:

Time first. Enforce NTP from a common, trusted source across every host. Log in UTC everywhere and record the offset. Nothing else works until this does.
Centralize with structure. Ship to a central store (a SIEM, or a log pipeline built on something like the Elastic stack, OpenSearch, Loki, or a managed platform) and normalize to a schema at ingest. Use a pipeline layer (Cribl, Logstash, Vector, Fluent Bit) to parse, enrich, and drop noise before indexing, which also controls the cost that drives the retention lies.
Log the fields that matter. Enable command-line process auditing (Event ID 4688 with the GPO, or Sysmon Event ID 1 with a curated config such as the widely used community baseline). Turn on PowerShell script block logging (Event ID 4104). Enable CloudTrail data events for sensitive buckets, and a Kubernetes audit policy scoped to writes and exec.

Then do the part the control actually asks for: review. Build a small set of high-signal detections you trust and tune them against your real baseline until the false-positive rate is livable. A dozen reliable alerts beat a thousand ignored ones. Write them as code, version them, test them, and treat them like software (detection-as-code). Run periodic threat hunts against the centralized data for the things too subtle to alert on: anomalous service-account logons, first-time parent/child process pairs, outbound connections from servers that should never initiate them.

And validate. Run atomic tests, generate the event you claim to detect, and confirm it (a) was collected, (b) was parsed, and (c) fired. An untested detection is a hypothesis, not a control. The number of “enabled” alerts that silently broke when a log source changed format would embarrass the entire profession if anyone measured it.

The Bottom Line

Nobody gets fired for buying a SIEM. Plenty of people get breached behind one. The logs were there the whole time, dutifully collected, faithfully retained, gloriously unread, and the forensics team will find the smoking gun three weeks after the attacker left, in an index everyone had access to and no one had opened. Collection is a purchase order. Detection is a discipline, and disciplines require someone whose job is to actually look. Until then you don’t have a security control, you have a very expensive write-only database and a clean audit report to bury with it.

Your logs already saw it. That was never the problem.

Patch Cadence vs. Patch Theater

2026-07-08T00:00:00+00:00

Every organization has a patching policy. Almost none of them can tell you, with a straight face and real data, what percentage of their exploitable assets got patched within the window that policy promises. These are not the same claim, and the distance between them is where breaches actually happen. “We have a patching policy” is a statement about a PDF. “We patch” is a statement about the world, and the world is considerably less cooperative than a PDF.

The Standard

CIS Critical Security Control 7, Continuous Vulnerability Management, is refreshingly unromantic about what it wants. It asks you to do four things and to keep doing them: establish and maintain a documented vulnerability management process (7.1), establish and maintain a remediation process with defined timelines by risk (7.2), perform automated operating system patch management (7.3) and automated application patch management (7.4), and perform authenticated vulnerability scanning on both internal and external-facing assets (7.5 through 7.7).

The word doing the heavy lifting is “continuous.” Control 7 does not describe a project. It describes a loop: discover assets, scan them with credentials, prioritize what you find against actual risk, remediate within a defined SLA, and then verify the fix landed by scanning again. The verification step is not decorative. A vulnerability you believe you remediated but never confirmed is still an open vulnerability, plus a false sense of security, which is strictly worse.

Note also that Control 7 leans on Controls 1 and 2. You cannot patch what you do not know you own. The control assumes you have an asset inventory and a software inventory, because remediation timelines are meaningless if the denominator, the total set of things that need patching, is unknown. Most “patch coverage” numbers are lies of omission: 98% of the assets we know about, and we do not talk about the ones we do not.

Where It Breaks Down

The failures are boringly consistent across organizations of every size.

Unauthenticated scanning masquerading as vulnerability management. A network scan that fingerprints a service banner over the wire tells you what a port looks like from outside. It does not tell you the patch level of the installed package, the version of a statically linked library buried in an application, or whether a kernel is running a version different from the one on disk because nobody rebooted. Control 7.5 says authenticated for a reason. Credentialed scans read the actual package database, the registry, the installed build numbers. If your scanner is not authenticating, you are measuring the paint, not the structure.

Patch coverage metrics that hide the reboot gap. Package managers are happy to report a patch as “installed” the moment the new binary is on disk. But a running process is still executing the old code loaded into memory. apt will happily update glibc while every long-running daemon on the box keeps the vulnerable version mapped until restart. The kernel is the obvious case, but shared libraries are the silent one. Tools like needrestart or checkrestart exist precisely because “patched” and “no longer running the vulnerable code” are different states, and most patch dashboards conflate them.

SLA timelines measured from the wrong clock. A policy that says “critical vulnerabilities patched within 7 days” sounds firm until you ask: seven days from when? From vendor disclosure? From when your scanner detected it? From when a ticket was opened? Each choice can differ by weeks. Organizations quietly reset the clock to the moment of internal detection, which conveniently excludes the discovery latency that is often the largest part of exposure.

The long tail nobody owns. OS patching gets automated because Windows Update, WSUS, dnf-automatic, and MDM profiles make it tractable. Control 7.4, application patching, is where it collapses. The Java runtime embedded in a vendor appliance. The OpenSSL statically compiled into an internal Go binary from three teams ago. The npm dependency tree of a service whose owner left the company. Container base images pinned to a tag and never rebuilt. These do not show up in the OS patch report, and no automated updater touches them.

Prioritization by CVSS base score alone. Control 7.2 asks you to prioritize by risk. A CVSS base score is not risk. It ignores whether the vulnerability is on an internet-facing asset, whether a public exploit exists, whether the affected component is actually reachable or loaded, and whether compensating controls apply. Treating a 9.8 on an isolated internal test box the same as a 7.5 on an exposed VPN concentrator is how remediation queues become undifferentiated backlogs of tens of thousands of “criticals” that no human triages.

Ephemeral and cloud assets outrunning the scan cycle. A weekly scan cadence assumes assets live longer than a week. Autoscaling groups, spot instances, and short-lived containers appear and vanish between scans, so they are either never assessed or assessed after they no longer exist. Meanwhile the image they were built from, the actual unit of remediation, sits unscanned in a registry.

Doing It Right

Start by refusing to report a coverage percentage without stating the denominator. Reconcile your vulnerability scanner’s asset list against your CMDB, your cloud provider’s inventory APIs, your EDR console, and your DHCP or NAC logs. The assets that appear in one source and not another are your actual attack surface. This reconciliation is tedious and permanent. Automate it or it will not happen.

Run authenticated scans. Provision least-privilege scan credentials (read-only, no interactive login, source-IP restricted, rotated) and confirm authentication success rates per scan, not just aggregate findings. A credentialed scan that silently fell back to unauthenticated is a common and dangerous failure mode; alert on the auth-success rate dropping.

Instrument the reboot gap explicitly. On Linux, incorporate needrestart output or check /var/run/reboot-required into your compliance reporting. On Windows, track pending-reboot registry keys. Report two numbers: “patch applied” and “patch active.” The delta is your real exposure and the metric your leadership has never seen.

Measure your SLA from detection, and separately measure detection latency itself (time from public availability to when your program first saw it). If discovery latency dominates your exposure window, no amount of fast remediation fixes it, and you need more frequent or continuous scanning rather than a faster ticket queue.

Prioritize with exploitability context, not base score. Enrich findings with exploit-availability feeds (something like a known-exploited catalog), internet-exposure data from your own external scanning, and asset criticality from your inventory. Feed these into remediation SLAs so that an exposed, actively exploited flaw gets a 48-hour clock while an internal, unreachable one gets a routine cycle. This is how you make the backlog triageable by humans.

For the application long tail, shift the unit of remediation upstream. Scan container images in the registry and fail builds on unremediated criticals rather than scanning running containers after deployment. Adopt software composition analysis (SCA) to enumerate embedded and transitive dependencies that OS package managers cannot see. Generate and retain an SBOM per build so that when a component turns out to be vulnerable, you can answer “where do we run this” in minutes rather than in an all-hands archaeology project.

Finally, close the loop with verification. Every remediation ticket should be closed by a subsequent authenticated scan confirming the finding is gone, not by a human asserting the patch was pushed. If your ticketing system lets an engineer close a vuln without rescan evidence, your process has a hole shaped exactly like human optimism.

The Bottom Line

Nobody gets compromised through the vulnerabilities in their policy document. They get compromised through the ones in the gap: the asset that was not in the inventory, the library that was patched on disk but running in memory, the appliance nobody owned, the scan that quietly fell back to unauthenticated in March and has been lying ever since. A patching policy is a promise you make to an auditor. Patching is a promise you keep to an attacker, and the attacker is the only one checking your work.

You will not close the gap entirely. You will only ever make it smaller, and knowable, and honest. That is the whole job. The organizations that survive are not the ones that patch fastest. They are the ones that know, to the asset, what they have not patched yet.

File under: things you already knew, filed anyway.

Least Privilege, Actually Enforced

2026-07-01T00:00:00+00:00

Everyone has a least-privilege policy. It lives in a Confluence page nobody has opened since the last audit, it uses the word “shall” a lot, and it has approximately zero effect on who can read the payroll database at 2 a.m. Least privilege is the security principle most universally endorsed and least frequently enforced, because writing the policy costs a meeting and enforcing it costs you the goodwill of every engineer who has ever been granted sudo “just to unblock a deploy.” The uncomfortable truth is that access accretes. It only ever accretes. And the access review that was supposed to prune it back is, in most shops, a spreadsheet that gets rubber-stamped once a year by a manager who has no idea what any of the entitlements mean.

The Standard

CIS Critical Security Control 6, Access Control Management, is not subtle about what it wants. The control covers the full lifecycle of access: granting, using, revoking, and reviewing. The parts practitioners skip are Safeguards 6.1 and 6.2 (a documented process to grant and to revoke access), 6.7 (centralizing access control through a directory or SSO where feasible), and above all 6.8, which asks you to “define and maintain role-based access control” by determining and documenting the access rights necessary for each role and reviewing them.

The word doing the heavy lifting there is maintain. Anyone can define an access model on a whiteboard. CIS is asking for the boring, recurring, adversarial work of confirming that the access people actually hold still matches the access they are supposed to hold. Control 5, Account Management, is the sibling you cannot ignore: an inventory of accounts, disabling dormant ones, and managing service accounts. Least privilege is meaningless if you do not know the accounts exist, and Control 6 quietly assumes you have already done Control 5. Most organizations have not.

Read together, the two controls describe a closed loop: you know every identity, you grant each identity the minimum entitlements its role requires, you have a mechanism that revokes those entitlements when the role changes, and you periodically verify that reality matches intent. It is a loop. The failure is almost always that it is not closed.

Where It Breaks Down

The first break is that “role-based” access control is aspirational fiction in most environments. What you actually have is entitlement-based access control with a role-shaped label glued on top. Someone requests access to a specific S3 bucket, a specific Jira project, a specific pg_hba.conf line, and it gets granted directly to their principal. The “Developer” role in your IdP maps to three group memberships; the other forty things a developer can touch were granted one ticket at a time. When you go looking for “what does this role grant,” there is no answer, because the role was never the unit of provisioning.

The second break is standing access to everything, all the time. AWS IAM policies with "Action": "*" on "Resource": "*" because scoping them was hard and the deadline was Friday. Kubernetes ClusterRoleBinding to cluster-admin because someone could not figure out which verbs on which resources the CI runner needed. Domain accounts in Domain Admins because a vendor’s installer asked for it in 2019. Every one of these is a permanent grant for an intermittent need, and permanence is the enemy.

The third break is the machines. Service accounts, CI/CD tokens, OAuth client credentials, and cloud instance roles now outnumber human identities by a wide margin, and they are almost never reviewed. A human at least leaves the company and triggers an offboarding checklist. A service account lives forever, its secret rotated never, its permissions granted by whoever stood up the integration and understood by no one. The static AWS access key checked into a Terraform state file five years ago still works, and it can still assume a role that can delete production.

The fourth break is the review itself, which is theater. The classic failure mode is the annual “user access review” where a system exports a list of usernames and entitlement codes to a spreadsheet, and line managers are asked to certify them. The manager sees APP_FIN_RW_PROD next to an employee’s name, has no idea what it grants, knows that clicking “revoke” might break something and generate a support ticket with their name on it, and clicks “approve all.” Certification rates of 99 percent are not a sign of clean access. They are a sign that nobody read anything. A review that never revokes anything is not a control. It is a compliance artifact.

The fifth break is that even when someone wants to revoke, the revocation path does not exist. Access was granted directly in the resource, out of band from the IdP, so there is no central place to pull it. Nested group memberships mean removing someone from one group does nothing because they inherit the same rights through two others. Access granted through a break-glass account has no owner to notify. You end up with orphaned entitlements that no automated process will ever clean up because no automated process knows they are there.

Doing It Right

Start by making the identity provider the source of truth, per Safeguard 6.7. If access can be granted outside your SSO/IdP, you cannot review it and you cannot revoke it. Federate everything that speaks SAML or OIDC. For the systems that do not, put them behind SCIM provisioning or, at minimum, a documented provisioning pipeline that flows through the IdP. The goal is a single point where deprovisioning actually deprovisions.

Then attack standing privilege directly. The single highest-leverage change is moving from persistent grants to just-in-time access. Human access to production should be requested, time-boxed, and expired automatically. This is what PAM tooling and cloud-native mechanisms like AWS IAM Identity Center permission sets with session policies, or Azure PIM eligible assignments, exist to do. An entitlement that expires in eight hours does not need an annual review. It reviews itself.

For what cannot be made ephemeral, scope it. Replace wildcard IAM policies with explicit actions and resource ARNs, and use conditions (aws:SourceIp, aws:PrincipalTag) to constrain further. Replace cluster-admin bindings with Roles scoped to a namespace and the specific verbs the workload needs. Read your cloud provider’s access analyzer output, which tells you which granted permissions were never used, and delete them.

Treat service accounts as first-class review targets. Every non-human identity needs a named human owner, a documented purpose, an expiry or rotation schedule, and a place in the same review cycle as humans. Prefer short-lived, workload-identity-federated credentials (OIDC-based, IRSA, workload identity) over long-lived static keys so there is nothing to leak and nothing to review.

Finally, fix the review so it can say no. Do not certify entitlement codes; certify against a defined role model, so the reviewer’s question is “should this person be a Developer” instead of “what is APP_FIN_RW_PROD.” Feed the review with usage data: an entitlement not exercised in 90 days is a revocation candidate by default, and the burden is on the owner to justify keeping it. Make revocation the cheap path and retention the one that requires effort. Track your revocation rate as the actual metric. A review cycle that revokes nothing is broken by definition, regardless of how many boxes got ticked.

The Bottom Line

Least privilege is not a policy problem. It is a garbage-collection problem, and you have never once run the collector. The document that says “users shall have minimum necessary access” is true the moment it is written and false by the end of the week, because access is granted continuously and reclaimed approximately never. The organizations that get breached through over-permissioned accounts are not the ones without a policy. They all have a policy. They are the ones whose access review approved everything, forever, because saying no was harder than saying yes. Close the loop or stop pretending you have one.

Access granted is access forever, unless you go take it back. You won’t.

MFA Fatigue and Push-Bombing

2026-06-30T00:00:00+00:00

We bolted push notifications onto authentication because passwords were a disaster and SMS one-time codes were worse, and for a brief, hopeful moment it looked like we’d solved something. Then attackers discovered that a button which says Approve will, given enough requests at 3 a.m., eventually get pressed. The control we deployed to stop credential theft became a control that launders credential theft into account takeover, one weary thumb at a time. This is not a failure of the technology so much as a failure to read the manual that shipped with it.

The Standard

NIST Special Publication 800-63B (the Digital Identity Guidelines, Authentication and Lifecycle Management volume) does not actually contain a control called “push MFA.” It never did. What it defines are authenticators, classed by Authenticator Assurance Level (AAL), with specific requirements around phishing resistance, verifier impersonation, and what the document calls “authentication intent.”

Two concepts in 800-63B matter most here, and almost nobody implementing push notifications reads them.

The first is phishing resistance, formalized in the AAL3 requirements and discussed throughout §5. An authenticator is phishing-resistant when the authentication protocol cryptographically binds the verifier’s identity into the ceremony, so a credential proven to one party cannot be replayed against another. WebAuthn/FIDO2 does this via channel binding to the origin. A push notification does not. A push approval is a bare yes/no decision divorced from any cryptographic context about who is asking and why.

The second is authentication intent, defined in §5.2.9. NIST is explicit: the authentication process should “establish that the claimant is the entity attempting to authenticate,” meaning the human pressing the button actually initiated the login. A naked push prompt establishes that someone has the phone and is willing to tap. It establishes nothing about intent.

800-63B also restricts what it calls out-of-band authenticators (§5.1.3) and is openly skeptical of unauthenticated approval flows. The document has, across revisions, steadily downgraded the standing of anything that relies on a user making a security decision under ambiguity. The standard, in other words, told you the simple push prompt was weak. You shipped it anyway because the UX was clean.

Where It Breaks Down

The failures are specific and they repeat across organizations like a liturgy.

Simple approve/deny with no context. The dominant deployment pattern is a single prompt: Sign-in request: Approve / Deny. No number to match, no location, no application name, no request count. The user has been trained by hundreds of legitimate prompts to treat the button as a speed bump. Attackers who have already harvested the password (via a reverse proxy phishing kit, credential stuffing, or an infostealer dump) simply replay the login and wait. This is push-bombing (or MFA fatigue): fire the authentication attempt repeatedly until the prompt becomes an annoyance the user dismisses by approving it.

No rate limiting on push generation. Many IdP configurations will happily emit a push notification on every authentication attempt with no throttling, no exponential backoff, and no lockout after N rejected or unanswered prompts. The attacker controls the volume. The user controls only their patience, which is finite.

Self-service enrollment with no binding integrity. 800-63B §6.1 is specific about binding authenticators to identities with appropriate assurance. In practice, enrollment frequently happens over the same weak first factor it’s supposed to strengthen: a user with a phished password enrolls the attacker’s device because the enrollment flow only re-verified the password. Now the second factor belongs to the adversary, permanently, and the legitimate user never sees a prompt.

Fallback paths that defeat the control entirely. The strong factor is push; the fallback is SMS OTP, or worse, an email magic link, or a help-desk reset with knowledge-based verification. Attackers don’t attack your strongest authenticator. They attack the weakest one you’ll accept, and 800-63B’s whole AAL model collapses the moment a high-assurance session can be established through a low-assurance recovery flow.

Conflating “we have MFA” with AAL2 or AAL3. Organizations check the MFA box for compliance and assume they’ve reached an assurance level. A bare push notification is, on a good day, a marginal AAL2 implementation, and only if you ignore the verifier impersonation concerns. It is categorically not AAL3 because it is not phishing-resistant. The audit said “MFA: yes.” The threat model didn’t care.

No telemetry on prompt rejection. A user who declines five prompts in two minutes is a screaming signal. Most deployments log the eventual approval and discard the pattern of preceding denials. The single most valuable detection signal for push-bombing is routinely thrown on the floor.

Doing It Right

You do not need to rip everything out tomorrow. You need to stop treating the bare prompt as adequate and start aligning to what 800-63B actually asks for.

Move to phishing-resistant authenticators wherever you can. This means FIDO2/WebAuthn with hardware security keys or platform authenticators (passkeys backed by a TPM or secure enclave), bound to the relying party’s origin. This is the only category 800-63B treats as genuinely phishing-resistant at AAL3. For privileged accounts, administrators, and anything touching identity infrastructure itself, this is not optional. It is the point.

If you must run push, run number matching, properly. Number-matching forces the user to read a value from the login screen and type it into the prompt, which restores a thin layer of authentication intent (§5.2.9) and breaks pure-volume push-bombing. Pair it with contextual display: application name, geographic location, IP, and a visible count of recent attempts. Context is what lets a tired human make the decision the standard assumes they’re making.

Rate-limit and backoff on the verifier side. Cap push generation per account per interval. Implement exponential backoff. After a threshold of denied or ignored prompts, lock the authentication flow and require step-up or administrative intervention, not another prompt. This is the throttling 800-63B §5.2.2 contemplates for verifier compromise resistance, applied to the push channel.

Fix enrollment and recovery to match the assurance you claim. Authenticator binding (§6.1) should require an existing strong factor, not just a password. Recovery flows must not establish a session at a higher AAL than the recovery method’s own assurance. Kill KBA. Route account recovery through verified, supervised channels for high-value accounts. The recovery path is the real authenticator; treat it that way.

Instrument prompt rejection and surface it. Feed denied-prompt patterns, impossible-travel signals, and prompt-storm bursts into your SIEM or ITDR tooling. Alert on the burst, not just the breach. The fatigue attack has a loud, recognizable signature before the fatal approval, if anyone is looking.

Bind sessions and shorten their reach. Pair strong authentication with token binding, conditional access policies keyed to device posture, and aggressive re-authentication for sensitive operations. A phished session token is its own attack class; phishing-resistant login means nothing if the resulting bearer token roams freely for thirty days.

The Bottom Line

Push-based MFA didn’t fail because it was a bad idea. It failed because we deployed the convenient version, declared victory, and stopped reading at the part of 800-63B that explains why the convenient version doesn’t work. The guidance was on the table the whole time. The control became the thing it was meant to prevent precisely because we optimized for the tap and not for the intent behind it.

You will read this, agree with all of it, and the bare approve/deny prompt will still be live in production next quarter because someone in another meeting decided number matching “adds friction.” It does. That’s the friction doing its job. The attackers already know your users will tap the button. The only open question is when.

Approve / Deny. You already know which one they’ll press.