IPsec Authentication Header is a security component that verifies data came from a trusted source and was not altered in transit. It adds integrity, origin authentication, and anti-replay protection to IP packets, but it does not encrypt the payload, so confidentiality must come from other controls.
What IPsec Authentication Header Does
Authentication Header, or AH, is the IPsec component that protects packet integrity and source authenticity at the IP layer. It helps receivers detect tampering and replay, but it does not provide confidentiality, so it must be paired with other controls when data secrecy matters.
That distinction matters because AH secures the packet, not the contents in a privacy sense. It is designed for environments where the priority is proving that traffic came from the expected source and arrived unchanged, such as control-plane traffic or trust-sensitive internal links.
How AH Protects Traffic Without Encrypting It
AH adds an authentication value across fields of the IP packet that are meant to remain stable in transit, so any modification is detectable. It also includes anti-replay protection, which helps prevent an attacker from capturing a valid packet and resending it later to trigger a stale or duplicated action.
Because AH does not encrypt the payload, anyone who can observe the traffic may still see the packet contents. That means AH can support integrity and authenticity requirements while leaving confidentiality to separate encryption, network segmentation, or application-layer protections.
Where AH Fits in IPsec Designs
AH is most useful when the security requirement is trust in packet origin and integrity, not secrecy. In practice, that means architects must decide whether AH alone is sufficient or whether Encapsulating Security Payload, transport encryption, or tunnel encryption is also required to protect the same traffic path.
That choice is often shaped by routing, compatibility, and inspection requirements. Some environments prefer integrity-only protection for specific internal traffic flows, while others avoid AH because middleboxes, NAT, and packet-path changes can complicate deployment.
Operational Considerations for AH Deployments
AH only works when both peers share the same security expectations for the packet path, the replay window, and the protected traffic scope. Misalignment on those basics can lead to failed sessions, false integrity failures, or a design that appears protected while leaving sensitive data visible on the wire.
It also demands careful coordination with key management and packet handling features in the network stack. If the environment changes frequently, or if confidentiality is a requirement, teams often find that a broader IPsec design is easier to operate consistently than AH alone.
Risk and Threat Considerations
AH reduces the risk of silent packet tampering, spoofing, and replay, but it does not stop traffic disclosure. If the protected data itself is sensitive, an observer can still collect and read the packet payload unless another control layer provides encryption.
Failure mechanism: An attacker who can intercept traffic may still learn the contents, and an attacker who can interfere with packet handling can sometimes create availability problems even when integrity checks are present.
Impact: The result can be exposed information, disrupted communications, or a false sense of end-to-end protection if AH is treated as a confidentiality control rather than an integrity control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | AH protects network-origin trust and packet authenticity between systems. |
| SC-8 — Transmission Confidentiality and Integrity | AH directly supports integrity in transit while leaving confidentiality to other controls. | |
| SC-23 — Session Authenticity | AH's anti-replay function aligns with preserving authenticity of network exchanges. | |
| Recommendation — Use packet-authenticating controls to verify peer identity for protected network exchanges. Apply SC-8 to protect transmitted data with integrity and encryption where needed. Use SC-23 to prevent replay and tampering in authenticated network communications. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | AH is part of a cryptographic protection design for data in transit. |
| Recommendation — Specify cryptographic protections for in-transit traffic according to confidentiality and integrity needs. | ||
| NIST CSF 2.0 | PR.DS-02 — Data-in-transit is protected | AH addresses integrity for data moving across networks. |
| Recommendation — Protect data in transit with controls that preserve integrity and, when required, confidentiality. | ||
Practitioner Guidance
Why practitioners should care: AH is a narrow control with a narrow strength, so the first deployment question is whether integrity and origin authentication are the real requirement. If the answer also includes secrecy, AH should be treated as only one part of the design.
Common misunderstanding: Teams sometimes assume that an IPsec label implies full packet protection. In reality, AH verifies the packet but does not hide it, so confidentiality requirements must be satisfied elsewhere in the stack.
Practitioner takeaway: Use AH only when you can clearly separate integrity needs from confidentiality needs, then validate that the surrounding IPsec and network design actually covers both.
Related resources from NHI Mgmt Group
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 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org