I used to break authentication. Here's what that taught me about building it.

Passwords, OTPs, passkeys, device binding, biometrics, risk engines and browser signals get discussed as if their presence settled something. What matters is the verification claim underneath. When a system says it has authenticated a user, has it established that the right person is present? The right device? An untampered browser? An informed human decision? An approval bound to the transaction being approved? Those are different claims. They fail in different ways, and they compose badly when the designer does not know which claim each layer is making.

Attackers force precision here because they do not care what a control was supposed to mean. They care what they can relay, replay, proxy, emulate, downgrade, exhaust, or get the user to approve anyway. A phishing-resistant method can sit inside a recovery flow that falls back to email. A fraud model can be fed inputs from a machine the attacker owns. Layered defenses do not help when every layer rests on the same broken assumption.

Defenders often evaluate controls one at a time. Attackers evaluate pathways.

An attacker does not ask whether your MFA is strong in isolation. They ask whether account recovery is weaker, whether the support desk can be talked round, whether a session upgrade is less protected than the initial login, and whether a high-assurance login is followed by low-assurance changes to the account. A passkey is rarely defeated directly. The attacker downgrades to the SMS fallback, social-engineers the recovery desk, or steals the session the passkey created.

That is what "bypassing MFA" usually means in practice. Authentication is rarely defeated as a single component. It is displaced. The attacker takes the cheaper adjacent route: the fallback flow, the human escalation path, the mobile prompt with no meaningful transaction context, the browser signal that can be copied, the recovery step everyone assumes will not matter. Very few systems are broken head-on. Many are broken diagonally.

Much of my work is on browser defenses, anti-fraud systems, identity protocols and session trust because those are boundary problems: places where one trust domain has to make claims about another.

A cryptographic protocol can be sound at its center. The boundary is where it degrades. A server infers things about a client it does not control. A helpdesk decides whether the caller is the person who should get access. A user interprets a prompt under time pressure. Each of those is a translation, and most translations lose something.

So the useful question is where the proof degrades as it crosses a boundary: from device to server, from cryptographic event to business decision, from login to session, from technical fact to human judgment. "Secure by design" is hard because the security claim has to survive contact with every interface around it.

From the offensive side the economics are obvious. The attacker needs one route that is cheap, repeatable and hard to detect at scale. The defender needs the whole path to hold, including the boring parts nobody presents on stage. That asymmetry is why authentication keeps turning into an arms race.

Defenders add signals, and attackers learn to simulate them. Defenders add browser integrity checks, and attackers instrument the browser, emulate the environment, or steal the artifact issued after the check. Defenders add MFA, and attackers answer with real-time adversary-in-the-middle phishing proxies that capture the session after the second factor, MFA fatigue (repeated push prompts until the user accepts), helpdesk pretexting, or malware riding the user's legitimate session. Defenders harden the login, and attackers move to session theft, recovery abuse and workflow manipulation after login.

None of this makes defense futile. It makes static defense futile. Unbreakable authentication is a fantasy. The realistic goal is a system whose security claims are explicit, whose failure modes are understood, whose compromise paths are expensive, and whose operations notice and contain what gets through.

The most useful thing offensive work left me with is a short hierarchy of questions, set out below. Teams that ask them early build different systems.

They bind approvals to meaningful transaction context instead of vague prompts. They remove fallback paths instead of decorating them. They treat recovery as a first-class security surface, as NIST SP 800-63B-4 now does by handling account recovery as an authentication event in its own right. They assume the client is negotiable. They keep identity proofing, authentication, session continuity and authorization separate instead of collapsing them into a fuzzy "logged in". They instrument for abuse patterns, not just uptime. They treat support staff, user interfaces and internal tooling as part of the authentication perimeter, because they are.

They are also harder to sell adjectives to. "Passwordless" or "zero trust" says nothing until someone answers what can be relayed, what fails open, and what happens when the user is deceived but technically compliant. Those are offensive questions, and defenders should be asking them first.

Here are the five questions applied to the cross-device Smart-ID+ QR flow and the signing relay from this site's Achilles' heel report. The relay was a proof of concept against SK's public demo portal, not a live bank, so this is an argument about the architecture.

What is the control asserting? When a user scans the QR code to log in and later confirms a transfer with PIN2 after matching a four-digit verification code, the bank reads that as "the account holder approved this transaction". What the flow establishes is narrower: someone holding the phone and the PIN approved a request whose code matched a code they saw on a screen.

Which part is cryptographic, which is environmental, and which is human? The signature is cryptographic and sound; Smart-ID splits the key, and the app's share never leaves the phone. Whether the screen showing the code is the bank's page is environmental. Whether the code on the phone matches that screen is a human comparison. The relay attacks the second part; the third still passes, because the codes really do match.

Which assumptions need the attacker to behave politely? The verification code assumes the user is looking at the bank's page. In the relay, the attacker serves a fake browser window that streams a real bank session from a container. The victim scans the genuine QR code inside it, the session lands in the attacker's browser, the attacker starts a transfer and mirrors the genuine code into the window the victim is watching. The codes match, so the victim approves.

Where are the fallback paths? Here the weaker path is a sibling of the strong one. Started on the same phone that holds the key, Smart-ID+ is, in Arnis Paršovs's words, fully phishing-resistant. Started from a QR code on another screen, it is only as good as that screen. Smart-ID+ went live at Bigbank and LHV in June 2026 and makes call-based fraud much harder, but it does not remove the cross-device path.

What stops a local failure from becoming an account-level one? One misled approval yields a transfer and a session the attacker can keep using. What limits the damage sits away from the prompt: transaction limits, delays on new payees, and server-side checks on where the session is actually being driven from.

Some security discourse treats offensive knowledge as adjacent to real defense work. I think that is backward: if you build authentication for real adversaries, offense is part of requirements gathering. Not every defender needs to write exploits, but someone in the room should ask what happens when a polished control is proxied, replayed, socially routed around, or embedded in a workflow nobody modeled. Without that, defense drifts toward ceremony.

That is the through-line of my work now. I research identity systems, browser trust, anti-fraud mechanisms and national authentication infrastructure because they sit on the fault line between claim and proof. I care about coordinated disclosure because public trust depends on someone naming where the abstractions break.

Seeing systems from the attacking side changed what I trust, what I question, and how I build. You stop asking whether a control looks strong, and start asking whether it still means what it claims when somebody is actively trying to make it lie.