Attackers are no longer trying to break in. They are logging in. Identity-based attacks have replaced network intrusions as the dominant breach method. Firewalls, antivirus and perimeter defences are largely irrelevant when an attacker already holds valid credentials.
Understanding what these attacks look like and how they work is the starting point for building authentication that can actually stop them.
An identity-based attack targets the authentication layer rather than the network. The attacker’s goal is not to break through a security control. It is to appear as a legitimate user and be granted access.
These attacks succeed because most authentication systems rely on factors the attacker can obtain or bypass: passwords that can be phished, codes that can be relayed and push notifications that can be approved through persistence or deception.
Enterprise security used to be built around perimeter defence. The assumption was that attackers were on the outside and legitimate users were on the inside. If you kept attackers out, you were protected.
That assumption no longer holds. Cloud services, remote work and third-party access have dissolved the perimeter. Users authenticate from anywhere. Applications live outside the corporate network.
Verizon’s Data Breach Investigations Report consistently identifies credential compromise as the top initial access vector in enterprise breaches. The perimeter failed because the perimeter moved. The identity layer is now the primary attack surface and for most organisations it is far less protected than the network ever was.
Phishing is the most common starting point for identity-based attacks. An attacker sends a convincing email directing the victim to a fake login page. The victim enters their credentials. In real-time relay attacks, those credentials are forwarded immediately to the legitimate service, which responds with an MFA challenge. The fake site mirrors the challenge back to the victim, who responds. The attacker now has an authenticated session.
The entire exchange takes seconds. The credentials are valid. The session is legitimate. The victim has no indication that anything happened.
Once an attacker holds a valid username and password, push-based MFA is the remaining obstacle.
Attackers trigger repeated authentication requests against the target account. The user receives push after push asking them to approve a login they did not initiate. Most users eventually approve one, out of frustration, confusion or the mistaken belief that the notifications are a technical error.
A single approval hands the attacker a valid authenticated session.
Not every identity-based attack requires the attacker to complete an authentication. Session hijacking targets the session token issued after a successful login.
Once a user has authenticated, their browser holds a session cookie that proves they are logged in. An attacker who captures that cookie does not need credentials or MFA. They import the cookie into their own browser and inherit the authenticated session.
Infostealer malware, adversary-in-the-middle proxies and cross-site scripting attacks are the main capture methods.
Session tokens are a single point of failure that sits downstream of even the strongest login controls.
SMS codes, time-based OTPs and push notifications share the same fundamental weakness. They authenticate a factor, not a person in a specific context.
A code that can be read can be relayed. A push notification that can be approved can be approved by anyone holding the device. None of these methods verify the biometric identity of the person authenticating, bind the login to a specific domain or confirm physical presence near the device being accessed.
Each attack type above exploits exactly these gaps. Phishing captures codes in transit. MFA fatigue exploits the approvals-based model. Session hijacking bypasses authentication entirely.
Phishing-resistant MFA closes these gaps at the architecture level, not through better training or stronger policies.
TokenCore devices require a live fingerprint match before any authentication is possible. Each credential is cryptographically bound to the domain it was created for. A spoofed login page cannot request a valid Token authentication because the domain does not match. Phishing-resistant MFA protects the authentication ceremony, but it does not by itself neutralize a stolen session token. Session protection, continuous access evaluation and rapid revocation are separate controls.
There are no codes to relay, no push notifications to approve and no credentials an attacker can reuse without the registered fingerprint.