Zero Trust in the Age of Generative AI
TL;DR
Generative AI is eroding the efficacy of perimeter-based security by enabling ultra convincing phishing, deepfakes, and automated social engineering. In this context Zero Trust is no longer optional — “never trust, always verify” must be the default. A strong way to achieve that is cryptographic device binding, such as device bound passkeys, which continuously assert both device and user authenticity. Below I explain why the new threat environment demands Zero Trust, how device binding fits into it, and steps your team can take to adopt these techniques.
Why generative AI breaks perimeter security
Perimeter or “trusted internal network” models assume that once you are inside the firewall or VPN, the user is benign. That assumption no longer holds in the age of generative AI.
- Generative AI can craft hyper realistic emails or messages, customized to an individual’s tone, context, and relationships. Attackers can weave in personal details gleaned from public data to bypass traditional filters and awareness heuristics.
- Deepfake voice or video impersonation can simulate a CEO or executive instructing someone to authorize wire transfers or share sensitive data. In one reported case, a deepfake was used during a video conference to trick participants, leading to a large financial loss.
- Generative AI also enables automated attack tooling: bots that research targets, build context, and escalate social engineering steps without human hands.
- In adversarial settings, AI may find or generate novel prompt injection or evasion techniques to bypass detection, or craft adversarial inputs to confuse models or detection systems.
Because attacks can impersonate internal actors or exploit trusted channels, relying on network location or “inside the perimeter” is no longer reliable.
Core principles of Zero Trust and heightened urgency now
Zero Trust starts from the assumption that no user, device, or network segment is trustworthy by default. The model requires verification for every access and continuous assessment of trustworthiness. Key principles include:
- Least privilege
Users and services get only the minimal permissions required, for the minimal time needed. - Explicit authentication and authorization
Every access request must be authenticated (who is requesting) and authorized (are they allowed) — continuously, not just once. - Continuous monitoring and risk evaluation
Trust is dynamic. Systems must collect telemetry, context, anomaly detection, and adjust access or revoke it when risk changes. - Segmented access and micro perimeters
Access is limited to workloads, applications, or resources rather than broad network zones. - Assume breach
Design as though attackers already have some foothold; focus on limiting lateral movement and rapid containment.
In the age of generative AI, “never trust, always verify” is more urgent because attackers can convincingly impersonate humans or internal systems. The network can no longer serve as a proxy for identity or integrity.
Device binding and cryptographic assurance in Zero Trust
One of the strongest ways to enforce continuous trust is cryptographic binding of a user’s session to a specific trusted device — in other words, device bound passkeys or attestable authenticators.
What is device binding (device bound passkeys)?
- With standards like FIDO2 / WebAuthn, a public/private key pair is generated by the authenticator (for example, in a TPM, secure enclave, or hardware security key). The private key cannot be exported.
- A passkey can be device bound (only usable on the device where it was created) rather than synced across devices. That means even if the user’s cloud account is compromised, the private key cannot be used elsewhere.
- Because the device is cryptographically proven to hold the private key, the server can trust that requests are genuinely coming from that device and user, not an impostor or replay from another endpoint.
Why device binding is especially valuable now
- It is phishing resistant: attackers cannot simply trick a user into giving credentials, because the private key never leaves the device and is not transferable.
- It binds identity to device posture. Even if a user’s identity is spoofed or session tokens stolen, requests lacking device authentication will fail.
- It enables continuous revalidation: for each transaction or API call, the backend can check that the request originates from the correct device bound key, reducing session hijacking risks.
- In enterprise environments, the use of device bound passkeys allows stronger control since employees cannot sync corporate passkeys to their personal devices.
- Note: some recent standards level issues such as CTAP protocol surfaces have been discovered and mitigated (for example CTRAPS attacks) — robust implementations must pay attention to authenticator and client API hardening.
Thus device binding offers a cryptographic root of trust that supports Zero Trust’s “verify every request” philosophy.
How to adopt device bound passkeys in a Zero Trust architecture
Implementing device bound passkeys is nontrivial in enterprise financial or fintech environments, but it can be phased. Here’s a pragmatic path forward:
- Start with high value users and sensitive operations
Begin by enabling device bound passkeys for privileged accounts, administrators, finance staff, or API clients. These are the high risk assets. - Integrate with your identity provider or SSO
Ensure your IdP or authentication platform supports FIDO2 device bound passkeys and attestation enforcement. - Mandate attestation enforcement
Require the authenticator to supply attestation evidence to prove the device and authenticator are genuine. Reject weak or simulacrum keys. - Enroll backup authenticators
Since device bound passkeys cannot be exported, you must register a second or third authenticator per user to allow recovery if a device is lost. - Deploy continuous session binding
Don’t just authenticate at login. For every sensitive action or API call, verify the device bound credential is still present and valid. Use mutual TLS, token signatures, or header attestation to ensure ongoing binding. - Monitor and respond
Feed telemetry from device authentication into your Zero Trust risk engine. Track failed binding attempts, unusual device changes, or anomalous behavior for real time policing. - Roll out progressively to broader user base
Once stable for high value users, phase the approach to all employees or customers. But maintain fallback paths for devices that cannot support it. - Educate and plan fallback or compliance
Make sure your operations, support, HR, and security teams understand how to onboard, deprovision, and recover device bound keys in alignment with your security model and regulatory needs.
Conclusion
The rise of generative AI transforms the threat landscape. Attackers can impersonate voices, craft perfect forgeries, and scale social engineering automatically. In this environment, perimeter defenses lose relevance. Zero Trust — the model where every access requires verification — becomes essential. Device bound passkeys provide a cryptographic anchor in that model, continuously validating both user and device in a way passwords or tokens cannot. If your security or product team can adopt device bound passkeys as part of a Zero Trust architecture, you’ll be far better positioned to defend against AI enabled threats rather than scrambling to react after a breach.
Sources & Further Reading
- https://link.springer.com/article/10.1007/s10462-024-10973-2
- https://www.ibm.com/think/insights/generative-ai-social-engineering
- https://www.procyon.ai/cloud/blogs-passkeys-and-security-2.0-concepts/
- https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2
- https://www.corbado.com/blog/device-bound-synced-passkeys
- https://www.onespan.com/blog/device-bound-passkeys
- https://fidoalliance.org/white-paper-fido-authentication-for-moderate-assurance-use-cases/
- https://arxiv.org/abs/2412.02349