How should security teams choose between PAP, CHAP, and EAP for authentication in a real deployment?

Use PAP only when nothing stronger is available, because it sends credentials in plaintext and is easy to intercept. CHAP reduces exposure by hashing a password with a server challenge, but the cleartext payload can still be attacked. EAP is the most flexible option, but the right method depends on certificate handling, provisioning complexity, and the environment’s security requirements.

Why PAP, CHAP, and EAP Are Not Interchangeable

These protocols solve different authentication problems, so the right choice depends on how much trust you place in the network path, how credentials are provisioned, and whether you need interoperability with modern identity systems. PAP is simplest but weakest. CHAP adds challenge-response protection for a password. EAP is a framework that can carry stronger methods, including certificate-based options, when the environment supports them.

A deployment decision should start with the threat model, not the protocol name. If the link can be observed or relayed, plaintext password exchange is a non-starter. If the deployment needs broad device or enterprise compatibility, you may still need a method that can negotiate multiple authenticators or integrate with directory, certificate, or network access infrastructure.

Protocol choice also affects operations. PAP is easy to configure and troubleshoot, but that simplicity shifts risk onto the transport. CHAP reduces direct exposure of the password, but it does not solve weak password policy, replay-resistant design limitations, or poor server-side secret handling. EAP is more flexible, but flexibility introduces implementation decisions around identity proofing, supplicant support, certificate lifecycle, and backend policy.

What Each Method Actually Protects, and What It Does Not

PAP protects almost nothing beyond basic compatibility. Because the secret is sent in a form that can be intercepted, it is only acceptable where the transport itself provides strong protection and the operational environment leaves no better option. In practice, that makes it a legacy fallback rather than a preferred design.

CHAP improves on PAP by avoiding direct password transmission. The server issues a challenge, and the client responds with a value derived from the password and challenge, which helps against simple passive capture. Even so, CHAP still depends on the quality of the shared secret and the surrounding session security, and it does not provide the broader assurance that modern federated or certificate-backed methods can provide.

EAP is not one method, it is a container for methods. That matters because the security outcome depends on the EAP type selected. Some EAP methods can provide strong mutual authentication and certificate-backed trust, while weaker variants can still leave room for downgrade, poor validation, or fragile provisioning. The main question is not “EAP or not”, but “which EAP method, with which trust anchors, and with which lifecycle controls?”

Choosing the Right Method in a Real Deployment

Security teams should choose the least risky method that the environment can operate reliably. If you need a transitional or highly constrained setup, CHAP may be an improvement over PAP, but it should not be treated as a long-term end state. If the environment can support certificate issuance, validation, and revocation, EAP with a strong method usually offers the best balance of assurance and flexibility.

The practical decision point is whether the organisation can support the full identity lifecycle behind the method. Stronger methods often fail in deployment because certificate enrollment is brittle, device provisioning is inconsistent, or exception handling becomes the real authentication policy. That is why an authentication design should be judged on operational enforceability, not just protocol strength in isolation.

Teams should also consider whether the chosen method aligns with the access architecture. For environments that already depend on NIST SP 800-63 Digital Identity Guidelines, NIST SP 800-53 Rev 5 Security and Privacy Controls, or enterprise verification controls such as OWASP ASVS, EAP methods that support stronger authenticators and better lifecycle governance fit more naturally than legacy password exchange.

Risk and Threat Considerations

Protocol choice changes exposure at the point where credentials cross the network and where an attacker can intercept, replay, or coerce weaker authentication. PAP creates the largest exposure because the secret itself is directly at risk. CHAP reduces that exposure, but it still depends on password strength and on the attacker not being able to exploit a weaker surrounding trust boundary. EAP lowers risk only when the selected method is actually strong and correctly deployed.

Failure mechanism: Weak protocol choice, weak method selection, or poor lifecycle controls allow credential interception, replay, downgrade, or unauthorized access even when the authentication flow looks modern on paper.

Impact: The result can be account compromise, lateral movement into the network, or silent acceptance of weaker identities that were never meant to hold production access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	Guides authenticator strength and assurance choices for authentication methods.
Recommendation — Select the strongest authenticator the deployment can support and enforce its lifecycle.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Covers password, token, and authenticator lifecycle for PAP, CHAP, and EAP deployments.
Recommendation — Manage authenticators through issuance, rotation, and revocation controls.
OWASP ASVS	V6 — Authentication	Addresses authentication method strength, verification, and implementation safeguards.
	V10 — OAuth and OIDC	Supports the stronger identity patterns often paired with modern EAP-backed access designs.
Recommendation — Verify that the chosen authentication flow resists interception, replay, and weak enrollment. Use stronger federation patterns when the deployment can replace legacy password exchange.
CIS Controls v8	CIS-5 — Account Management	Authentication choice depends on controlled account provisioning and lifecycle hygiene.
Recommendation — Centralise account lifecycle control before widening access to stronger authentication paths.

Practitioner Guidance

What to verify: Do not approve an authentication method until you know where the secret lives, how it is provisioned, how it is rotated, and whether the transport or tunnel actually protects the exchange. If those details are unclear, the method is not ready for production.

Decision rule: If the deployment can support certificate-based or otherwise strongly authenticated EAP, prefer that path; if not, treat CHAP only as a constrained fallback and reserve PAP for legacy compatibility cases that have compensating transport protection and explicit risk acceptance.

Practitioner takeaway: Choose the method that your operating model can sustain, because authentication strength collapses quickly when provisioning, validation, and revocation are weak.