PAP

PAP in context

PAP is the weakest style of password exchange because the secret is sent as-is rather than verified through a stronger challenge-response flow. That makes it a legacy compatibility choice, not a modern trust mechanism, and it should be understood as an exception path that depends heavily on the protection around it.

In practice, PAP matters because the protocol itself does not protect the credential from disclosure. If the transport or session is not strongly protected, any observer on the path may recover the password and reuse it elsewhere. The security question is therefore not just whether PAP works, but whether the surrounding environment can compensate for its inherent exposure.

Why PAP is considered insecure

PAP exposes a password directly instead of proving knowledge of it indirectly. That means the protocol offers no intrinsic resistance to interception, replay, or passive credential capture. Compared with challenge-response authentication, PAP creates a much thinner security boundary and leaves far more responsibility to the transport layer and surrounding controls.

This is why PAP is generally unsuitable outside tightly controlled situations. Even where a system accepts PAP for compatibility, the risk is not limited to one login event. A captured password can be reused against other systems, especially where users recycle secrets or where the account has broader access than the original connection was meant to provide.

Where PAP still appears

PAP usually survives in older network access, remote access, or embedded environments where the client and server support only simple password exchange or where interoperability requirements limit stronger methods. In those settings, PAP is often tolerated as a fallback rather than a preferred design.

That fallback status is important. When PAP appears in a stack, it often signals technical debt, constrained device support, or incomplete migration to stronger authentication. The practical issue is not merely the protocol name, but whether the organisation has accepted a weaker trust model for a specific system boundary and whether that exception is still justified.

How to interpret PAP in an authentication design

PAP should be treated as a compatibility mechanism that requires compensating controls, not as a baseline authentication standard. Its security depends on encrypted transport, strict network boundaries, and stronger account protections around the password being sent. Without those layers, PAP exposes the organisation to straightforward credential theft.

When evaluating PAP, the key design question is whether the password can ever traverse an untrusted channel. If the answer is yes, the protocol is inappropriate. If the answer is no only because of other controls, then those controls are carrying the real security burden, not PAP itself.

Risk and Threat Considerations

PAP creates direct credential exposure, so the main risk is interception of reusable passwords in transit. That can lead to account takeover, lateral movement, and access to any systems that trust the same credentials or the same user identity.

Failure mechanism: An attacker or passive observer captures the password because PAP sends it in a simple form rather than hiding it behind a challenge-response exchange.

Impact: The stolen secret can be replayed or reused, turning a single exposed login into broader compromise if the account is valid elsewhere or has elevated access.

Practitioner Guidance

Why practitioners should care: PAP should be treated as an exception requiring documented justification, because its risk comes from the protocol design itself rather than from a rare edge case. Where it cannot yet be removed, the surrounding control environment has to do the heavy lifting.

What to watch for: Review whether PAP is still enabled for legacy compatibility, whether encrypted transport is mandatory, and whether any account using PAP has privileges that would amplify credential exposure. A weak protocol on a low-value account is still a credential leak; a weak protocol on a privileged account is much worse.

Practitioner takeaway: If PAP remains in use, treat it as temporary technical debt and prioritise migration to stronger authentication methods rather than normalising it as an acceptable steady state.

Related resources from NHI Mgmt Group

• How should security teams choose between PAP, CHAP, and EAP for authentication in a real deployment?
• Why does PAP create more authentication risk than challenge-based protocols?
• Why does using PAP with RADIUS increase risk for remote administrative access?
• Password Authentication Protocol (PAP)