EAP-FAST Explained: PAC Provisioning and Its Security Trade-offs

EAP-FAST — Flexible Authentication via Secure Tunneling — was developed by Cisco to replace LEAP after LEAP was broken. Its design goal was to get the protection of a TLS tunnel without requiring a certificate infrastructure, and understanding how it achieves that explains both its appeal and its weakness.

For the full comparison of EAP methods, see the companion article linked at the end. This one covers EAP-FAST specifically.

The Protected Access Credential

Where PEAP and EAP-TTLS build their tunnel using a server certificate, EAP-FAST uses a PAC — a shared secret provisioned to the client in advance.

The PAC has three parts. The PAC-Key establishes the tunnel. The PAC-Opaque is a blob the client presents to the server, which only the server can decrypt. The PAC-Info holds metadata such as the issuing authority and lifetime.

The appeal is straightforward: no PKI. No certificate authority, no certificate deployment, no renewal cycle, no expiry causing mass authentication failures. For an organisation without certificate management, that removed the main barrier to deploying 802.1X.

The three phases

Phase 0 — PAC provisioning. Optional, and only needed when the client has no PAC. This is the security-critical phase, covered below.

Phase 1 — tunnel establishment. The client and server use the PAC to establish a secure TLS tunnel.

Phase 2 — authentication. The actual credential exchange happens inside that tunnel, usually with MSCHAPv2.

Phases 1 and 2 are sound. Everything rests on how the PAC got there.

Provisioning, and the weakness

Three modes, and the exam point is the difference between them.

Anonymous in-band provisioning establishes an unauthenticated tunnel using anonymous Diffie-Hellman and delivers the PAC through it. Convenient — clients self-provision on first connection with no administrative effort.

The problem is inherent: an anonymous tunnel authenticates nobody. An attacker operating a rogue access point can complete provisioning with the client, and the MSCHAPv2 exchange that follows yields material for an offline attack on the user's password. The convenience and the vulnerability are the same feature.

Authenticated in-band provisioning uses a server certificate to authenticate the provisioning tunnel. Secure — and it requires the certificate that EAP-FAST existed to avoid, which undermines the original rationale.

Out-of-band provisioning distributes the PAC through a separate secure channel such as a management platform. Secure, and it reintroduces deployment effort.

So the honest summary: EAP-FAST is secure when provisioned securely, and provisioning it securely costs roughly what it was meant to save.

Where it stands now

The landscape changed after EAP-FAST was designed. Certificate management became far easier through device management platforms and automated enrolment, which removed much of the pain EAP-FAST addressed. PEAP remained widely supported across every client platform, while EAP-FAST support outside Cisco environments stayed patchy. And the emphasis on validating server identity — the lesson from PEAP misconfiguration — made anonymous provisioning look worse over time.

The result is that EAP-FAST is mostly encountered in existing Cisco deployments rather than chosen for new ones.

How it compares

Method	Tunnel established by	Main risk
EAP-TLS	Mutual certificates	PKI management overhead
PEAP	Server certificate	Client not validating the certificate
EAP-TTLS	Server certificate	Same as PEAP
EAP-FAST	PAC	Anonymous provisioning

Notice the pattern across all of them: each tunnelled method is only as strong as the mechanism that establishes trust before the tunnel exists. For PEAP that is certificate validation; for EAP-FAST it is PAC provisioning. That is the transferable idea, and it is what an exam question about either one is really testing.

If you are running it

Disable anonymous in-band provisioning. Use authenticated or out-of-band provisioning. Set a sensible PAC lifetime with automatic refresh, and have a process for revoking PACs on lost devices. And consider whether EAP-TLS is now achievable, since the certificate management that once made it impractical usually is not any more.

What to remember

EAP-FAST replaces the server certificate with a Protected Access Credential, avoiding PKI. Phase 0 provisions the PAC, phase 1 builds the tunnel, phase 2 authenticates inside it. Anonymous in-band provisioning is the vulnerability, exposing credentials to a rogue access point. Securing provisioning reintroduces the overhead EAP-FAST was designed to avoid.

Related reading: EAP methods compared · AAA and RADIUS · Wireless security