DEV Community

Kalyan Tamarapalli
Kalyan Tamarapalli

Posted on • Originally published at ktamarapalli.hashnode.dev

FIDO2 for CI/CD: Why Origin-Bound Hardware Authentication Beats TOTP and Push Approvals

Using WebAuthn as a Cryptographic Proof of Human Presence in Hostile Networks


Introduction: Authentication That Fails in Real Attacks

Most CI/CD systems rely on:

  • TOTP codes
  • Push notifications
  • Long-lived API tokens

These mechanisms fail under modern phishing and malware proxy attacks.

  • TOTP can be phished in real time
  • Push approvals can be tricked into blind acceptance
  • Tokens can be exfiltrated and replayed

These are not theoretical risks.

They are observed attack patterns.

This article explains why FIDO2 (WebAuthn) is categorically different — and why origin-bound hardware authentication is a necessary primitive for high-assurance CI/CD approval flows.


The Limits of TOTP and Push-Based MFA

TOTP and push-based MFA fail for structural reasons.

Key weaknesses:

  • The user types a secret into a potentially spoofed interface
  • The approval flow can be proxied or relayed by malware
  • The second factor is not cryptographically bound to the origin

These mechanisms prioritize usability and compatibility.

They do not provide strong guarantees about where the authentication is happening.

They confirm:

“The user has a factor.”

They do not confirm:

“The user is interacting with the correct system.”

That distinction matters in adversarial environments.


What FIDO2 Actually Guarantees

FIDO2/WebAuthn introduces stronger properties:

  • Origin binding: The hardware key signs the TLS origin
  • Phishing resistance: The key refuses to sign for mismatched domains
  • User presence verification: Physical interaction is required
  • No shared secrets: Private keys never leave the device

This creates a cryptographic guarantee:

A human physically interacted with a hardware token

at a specific origin

at a specific moment

That is fundamentally different from traditional MFA.


Origin Binding and DNS Hijacking

Consider a DNS hijacking or phishing scenario.

With TOTP:

  1. User is redirected to attacker-controlled domain
  2. User enters credentials + TOTP code
  3. Attacker relays the code in real time
  4. Authentication succeeds

The system sees valid credentials.

The attack works.


With FIDO2:

  1. User is redirected to attacker-controlled domain
  2. Browser requests WebAuthn signature
  3. Hardware key checks origin
  4. Origin mismatch detected
  5. Key refuses to sign

Authentication fails cryptographically.

No user judgment required.

No warning needed.

The attack is structurally blocked.

This is not a UI improvement.

It is a protocol-level guarantee.


Hardware-Backed Keys vs Software Authenticators

Not all WebAuthn implementations are equal.

Software authenticators (e.g., OS-level passkeys):

  • share trust with the host system
  • may be influenced by host compromise

Hardware-backed keys:

  • store private keys inside secure elements
  • require physical presence
  • resist extraction and tampering

This matters in hostile environments.

If the host is compromised, software-based authenticators may inherit that risk.

Hardware keys introduce a separate trust boundary.

That is the point.


Integrating FIDO2 into CI/CD Approval Flows

FIDO2 can be used as a primitive in CI/CD systems to:

  • gate deployment approvals
  • require per-action authentication
  • bind approval to specific commit hashes
  • prevent replay of authorization tokens

This changes the role of authentication.

From:

verifying identity

To:

verifying intent at the moment of action

Each deployment becomes a discrete, cryptographically verified event.

Not a continuation of a session.


From Authentication to Intent Verification

Traditional authentication answers:

Who is this?

FIDO2 enables systems to ask:

Did this human physically approve this specific action right now?

That is a stronger question.

And a more relevant one in CI/CD systems where:

  • sessions are long-lived
  • tokens are reused
  • actions are high-impact

FIDO2 enables per-action authorization grounded in human presence.


Performance and Usability Trade-offs

Hardware-backed authentication introduces friction:

  • physical interaction
  • device handling
  • initial setup overhead

But the performance cost is small:

  • typically a few hundred milliseconds to a few seconds

The security benefit is large:

  • elimination of phishing-based MFA bypass
  • resistance to real-time relay attacks
  • removal of shared secrets

This is an asymmetric trade-off:

Small usability cost

Large security gain


Threat Model Boundaries

FIDO2 is powerful, but not complete.

It does not solve:

  • physical theft combined with PIN compromise
  • coercion of the operator
  • UI deception on a compromised host
  • approval context manipulation on the same device

That is why FIDO2 should not be used in isolation.

It must be combined with:

  • physical trust separation (e.g., isolated approval terminals)
  • contextual verification
  • governance controls

FIDO2 is necessary.

It is not sufficient on its own.


Conclusion: Hardware-Bound Intent Beats Software MFA

TOTP and push-based MFA are convenience mechanisms.

They improve security compared to passwords alone.

But they remain vulnerable to modern attack techniques.

FIDO2 changes the model.

It replaces:

  • shared secrets
  • user-entered codes
  • UI-driven approval

With:

  • hardware-backed cryptography
  • origin-bound verification
  • physical presence requirements

High-assurance CI/CD systems should treat origin-bound hardware authentication not as an optional upgrade…

…but as a foundational primitive.

Because in adversarial environments:

Identity is easy to simulate.

Physical, origin-bound intent is not.

Top comments (0)