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 Is a Poor Default and CHAP Is Only a Partial Step Up
PAP, CHAP, and EAP are not just three ways to log in, they reflect different assumptions about what the network can safely reveal during authentication. PAP is the weakest because the credential is sent in a form that is easy to intercept. CHAP improves that exchange, but it still relies on a legacy challenge-response model that leaves other parts of the session and deployment trust model exposed.
The practical question is not which protocol sounds “more secure” in isolation, but which one matches the deployment constraints. If the environment cannot protect authentication traffic end to end, PAP is usually an unacceptable fallback. CHAP may be tolerable in tightly controlled legacy environments, but it should not be treated as equivalent to modern authentication design.
For teams comparing these options, the main architectural issue is whether the protocol protects only the password exchange or the broader authentication workflow. A method can hide the cleartext password and still leave room for replay, downgrade, relay, weak peer validation, or poor secrets handling elsewhere in the stack.
What EAP Changes in a Real Deployment
EAP is not a single authentication method, it is a framework that can carry multiple methods with very different assurance properties. That flexibility is why it is usually the strongest choice in modern deployments, but it also means the security outcome depends on the specific EAP method, the server-side validation model, and how certificates, keys, or credentials are provisioned and maintained.
In practice, EAP becomes the right answer when the deployment needs stronger assurance than password-only schemes can provide, or when the environment must support enterprise features such as certificate-based trust, centralized policy, or device-aware access. The trade-off is operational complexity. A strong EAP design can fail if certificate enrollment, revocation, trust anchor management, or client provisioning is sloppy.
That is why “use EAP” is not a complete recommendation on its own. Security teams need to choose the actual EAP method, then confirm that it matches the environment’s identity stores, device management model, and failure tolerance. In many real deployments, the method choice matters more than the umbrella protocol name.
How to Choose the Right Method for the Environment
The decision usually comes down to three questions: can you avoid sending secrets in a way that can be captured, can you support the operational overhead of stronger authentication, and can your users and devices reliably complete the authentication flow without creating dangerous workarounds?
If the answer is no on all three, the deployment may still be stuck in a legacy posture, but that should be treated as a temporary exception rather than a design target. If certificate lifecycle management is immature, a certificate-heavy EAP option may create outages or support debt even though it improves security. If the environment is highly constrained, the team may need to phase the rollout rather than force a one-shot migration.
Use this NIST SP 800-63 Digital Identity Guidelines as the baseline for thinking about authenticator strength and assurance, then map the chosen method to the actual operational model. For implementation detail, the most relevant protocol references are RFC 9700: Best Current Practice for OAuth 2.0 Security for modern authentication hardening principles, and the EAP-related certificate path should be checked against RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens when certificate-bound trust is part of the design.
Risk and Threat Considerations
The main risk is assuming that “non-plaintext” automatically means “secure enough.” Legacy authentication often fails not because the password is literally exposed on the wire, but because the surrounding control plane is weak, including peer validation, credential reuse, downgrade handling, and poor monitoring of authentication failures.
Failure mechanism: Attackers can intercept weak exchanges, abuse reused credentials, replay or relay authentication material, or exploit weak deployment assumptions around certificates and server validation. A protocol that looks stronger on paper can still be undermined if clients accept unauthenticated peers or if administrators preserve legacy settings for compatibility.
Impact: The result can be account compromise, unauthorized network access, and a wider blast radius if the same credentials or trust anchors are reused across systems. In real environments, a weak authentication choice often becomes a foothold for lateral movement rather than a single isolated login failure.
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 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IA-5 — Authenticator Management | Authentication method choice depends on how secrets and authenticators are handled. |
| Recommendation — Manage authenticators so the chosen method can be issued, protected, rotated, and revoked reliably. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Real deployments must authenticate users with methods matched to required assurance. |
| IA-5 — Authenticator Management | PAP, CHAP, and EAP differ in how credentials and authenticators are protected. | |
| IA-9 — Service Identification and Authentication | Deployment authentication design often includes devices, services, and infrastructure peers. | |
| Recommendation — Use strong user authentication and phase out weaker legacy methods where possible. Control authenticator lifecycle so deployment security matches the protocol choice. Require strong mutual authentication for non-human peers when they are part of the access path. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Authentication method selection is part of access control design and enforcement. |
| A.8.5 — Secure authentication | The question is directly about choosing secure authentication methods in deployment. | |
| Recommendation — Specify stronger authentication controls for the environments that need them most. Select the authentication method that best fits the environment’s assurance and operational constraints. | ||
Practitioner Guidance
What to verify: Confirm whether the deployment actually supports the stronger method end to end, not just on the server. A secure choice on paper is still fragile if endpoint provisioning, certificate issuance, revocation, or client configuration cannot be enforced consistently.
Decision rule: If the environment cannot protect credentials in transit and cannot support stronger validation, treat PAP as a last-resort legacy exception only. If the team can support certificates, centralized policy, and lifecycle controls, prefer EAP with the most appropriate method for that environment rather than defaulting to CHAP for convenience.
Practitioner takeaway: Choose the method based on the full authentication system, not just the login handshake. In most real deployments, the right answer is to retire PAP, limit CHAP to constrained legacy cases, and use EAP only when its stronger assurance can be operationally sustained.
Related resources from NHI Mgmt Group
- How should security teams choose authentication for a .NET application that may need enterprise customers later?
- How should security teams choose authentication for Node.js apps that may become B2B products?
- How should security teams choose authentication for enterprise Rails apps?
- How should security teams choose between FIDO and certificate-based authentication?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org