Skip to main content

Phishing-Resistant Authentication: What Actually Makes It Resistant?

Phishing-resistant authentication is often described as “strong MFA,” but the important distinction is not simply the number of factors. It is whether an attacker can trick a user into approving an authentication that the attacker can reuse somewhere else.

Modern phishing frequently works in real time. A fake site can relay credentials to the real service, capture one-time codes, and immediately forward approval prompts. An authentication method becomes meaningfully phishing-resistant when the proof is cryptographically tied to the legitimate service or origin rather than being a reusable secret that can be copied or relayed.

This guide explains the main design properties behind that resistance and shows how ZTXBAS applies them.

1. Why Passwords and One-Time Codes Are Easy to Relay​

Passwords, SMS codes, and TOTP values are all pieces of information a user can type into the wrong place.

A phishing proxy can:

  1. present a convincing copy of a real login page
  2. collect the username and password
  3. forward them to the legitimate service
  4. ask the user for the SMS or TOTP code generated by the real service
  5. relay that code before it expires

The code can still be valid even though the user entered it on the wrong site, because the code itself is not bound to the site that requested it.

Push approval improves usability but can have a similar weakness if the user sees only a generic “Approve sign-in?” prompt. If the approval is not bound to the intended service, a user may approve a request initiated through a phishing session.

2. Biometrics Alone Do Not Create Phishing Resistance​

A fingerprint or face scan proves that a local user passed biometric verification on a device. By itself, that does not prove what the user intended to authenticate to.

The important question is what happens after the biometric check:

  • Which application or origin is the approval for?
  • Is that destination visible to the user?
  • Is the resulting proof bound to that destination?
  • Can the proof be replayed at another application?
  • Does the private key ever leave the device?

Phishing resistance comes from the protocol around the biometric check, not from the biometric sensor alone.

3. Origin Binding Ties the Approval to the Intended Application​

Origin binding is the central control in ZTXBAS.

When an application creates an authentication challenge, it includes its expected origin. ZTXBAS accepts the request only when that origin is registered for the application. The canonical origin is then carried through the challenge and shown to the user on the mobile device before approval.

For example, an approval created for:

https://app.example.com

cannot simply be repurposed for:

https://phishing.example.com

The phishing origin is not registered for the legitimate application, and the authenticated assertion contains the origin it was actually issued for.

This gives both sides something concrete to verify:

  • the user sees the destination they are approving
  • the relying application receives an assertion containing that same origin

The backend should still verify the origin claim after validating the assertion signature. Phishing resistance depends on enforcing the binding, not merely carrying the field.

Read the technical origin-binding documentation

4. Device-Bound Keys Keep the Private Credential on the Device​

ZTXBAS uses device-bound cryptographic keys. Private keys remain in the device's Secure Enclave or trusted execution environment where available, and biometric templates do not leave the device.

That changes the attacker's target.

There is no shared biometric secret for a phishing site to collect and reuse. The server receives a cryptographic proof produced by the enrolled device rather than a reusable password-like value derived from the biometric.

This distinction is important: the biometric unlocks or authorizes use of a device-held key; the biometric data itself is not sent to the relying application.

5. Short-Lived Signed Assertions Reduce the Value of Captured Proof​

After a successful challenge, ZTXBAS issues a short-lived ES256 JWT identity assertion.

The assertion includes information such as:

  • authenticated user
  • issuer
  • audience and origin
  • issue and expiry times
  • challenge identifier

The relying application verifies the JWT using the public JWKS published by the ZTXBAS server. It should validate the signature, expected algorithm, expiry, issuer where configured, and the expected origin before creating its own application session.

Because the assertion is signed and short-lived, it is not equivalent to a permanent bearer credential. Applications with stronger replay requirements can also track recently used challenge identifiers and reject reuse.

Read the JWT verification guide

6. The Relying Application Must Authenticate to the Authentication Service Too​

Phishing resistance is not only about the user side.

In ZTXBAS, applications sign API requests with HMAC-SHA256. Before a challenge is created, the server verifies that the request came from the registered application, that the requested origin belongs to that application, and that the user exists.

That prevents an arbitrary phishing site from simply asking the legitimate ZTXBAS server to create a valid challenge for itself under another application's identity.

The application secret therefore remains a server-side credential and should never be exposed in browser code or a mobile client.

Read about HMAC request signing

7. The User Still Needs Useful Context​

Cryptography can bind a request to an origin, but the user experience still matters.

A strong approval flow should show enough context for the user to recognize what they are approving. With ZTXBAS, the registered origin is displayed on the mobile device before approval.

This helps distinguish a genuine request from an unexpected one. It also avoids relying on vague approval prompts that provide no destination information.

Organizations should still educate users to reject unexpected authentication requests. Phishing resistance reduces the attacker's ability to reuse an approval; it does not make suspicious prompts harmless.

8. Phishing Resistance Does Not Replace the Rest of Access Control​

A phishing-resistant authentication event proves a specific identity assertion. It does not answer every authorization question.

Applications may still need to decide:

  • whether the user should have an account
  • which role the user has
  • which resource the user may access
  • whether the device is trusted
  • whether additional approval is required
  • how long the resulting session should last

Standalone ZTXBAS is designed to provide the authentication assertion to an application. The application remains responsible for its own session and authorization model.

When ZTXBAS is licensed with ZTXGate, the biometric capability is integrated into ZTXGate and can be used as part of broader access policy rather than requiring a separate ZTXBAS server.

9. How This Relates to Passkeys and WebAuthn​

Passkeys and WebAuthn are also designed to be phishing-resistant because their cryptographic credentials are scoped to the legitimate relying party rather than typed into arbitrary sites.

ZTXBAS uses a different interaction model: a server-mediated biometric push produces a signed JWT that the relying application verifies server-side.

The approaches can be complementary rather than mutually exclusive. A browser application may use passkeys for primary login while using ZTXBAS for a step-up flow, a mobile workflow, or another non-browser interaction that benefits from the same signed assertion model.

ZTXBAS is not FIDO certified.

10. Deployment Model Matters Too​

Authentication availability can become part of the security architecture when protected systems must operate without a public cloud dependency.

Standalone ZTXBAS is self-hosted and does not require a CoreZT account, telemetry service, or license server. It can also run in an air-gapped environment when required supporting services, such as an internal SMTP relay for enrollment mail, are available locally.

The ZTXBAS capability integrated with ZTXGate can likewise operate inside fully air-gapped ZTXGate deployments without a separate ZTXBAS server.

This does not make one deployment model universally better than another, but it is an important design question: what external services must remain reachable for authentication to continue working?

11. A Practical Evaluation Checklist​

When evaluating any authentication system described as phishing-resistant, ask:

  • Is the authentication proof cryptographically bound to the intended relying party or origin?
  • Can a user type or copy the primary proof into an attacker-controlled page?
  • Is the destination visible to the user before approval?
  • Are private keys device-bound and protected by platform hardware where available?
  • Does the server receive biometric data, or only proof that local biometric verification succeeded?
  • Are assertions short-lived and signed?
  • Does the relying application verify issuer, expiry, audience/origin, and algorithm rather than signature alone?
  • Can an attacker create valid challenges without possessing the relying application's server-side credential?
  • How are lost devices revoked and re-enrolled?
  • What network or cloud dependencies must be available during authentication?

A product should be able to answer those questions at the protocol and operational level, not only with an MFA label.

How ZTXBAS Applies These Properties​

ZTXBAS combines:

  • registered-origin validation
  • origin display before approval
  • device-bound keys protected by the mobile platform
  • biometric user verification on the device
  • HMAC-authenticated application requests
  • short-lived ES256 identity assertions
  • JWKS-based server-side verification

The result is an authentication flow in which the relying application can verify not only who approved the challenge, but also which origin that approval was issued for.

For implementation details, continue into the technical documentation or evaluate the standalone server directly.

Read the ZTXBAS DocsExplore ZTXBAS