What is a Security Association?

A security association (SA) is the negotiated set of security parameters – encryption algorithm, authentication method, keys, and lifetime – that two IPsec peers agree on before protected traffic can flow through a tunnel. Each direction of an IPsec tunnel maintains its own SA, and IKE renegotiates them on a schedule so encrypted traffic never has to stop.

Key takeaways

• An SA defines the keys, algorithm, and lifetime for one tunnel direction.
• IKE negotiates SAs and automatically rekeys them before they expire.
• Each IPsec tunnel maintains a separate inbound and outbound SA pair.
• A Security Parameter Index (SPI) identifies each SA on a device.
• VOS exposes IKE and IPsec SA state per tunnel for live monitoring.

On this page: Why it matters · How it works · Types · Security Associations & Versa · FAQ

Why are security associations important?

A security association is what actually protects traffic – not the tunnel configuration itself, but the live agreement each endpoint enforces on every packet. Without a valid SA, a peer has no key or algorithm to apply, so no protected traffic can move. Every SA carries a lifetime and must be renewed continuously: IKE renegotiates it before expiry so a working tunnel never pauses. When rekeying fails, the tunnel stops passing traffic even though its configuration still looks correct – why SA state is one of the first things operators check when diagnosing an outage.

The model also scopes security independently to each direction and peer pair, so a compromise on one tunnel does not expose others. That isolation is what lets large deployments – hundreds of branch sites, each with its own tunnels – operate without one failure cascading across the fabric.

What is a security association?

An SA is the record each endpoint keeps for one direction of one tunnel’s traffic: which encryption algorithm to use (AES-GCM or AES-CBC), which algorithm verifies integrity, the current session keys, and how long the agreement is valid before renegotiation. Two SAs – one inbound, one outbound – cover a tunnel’s traffic in both directions.

Each SA is uniquely identified by a Security Parameter Index (SPI), a 32-bit value the sender stamps on every packet, combined with the destination address and security protocol (AH or ESP). The receiver uses that triplet to find the matching SA and apply its keys and algorithms.

SAs are not configured directly; IKE negotiates them. Phase 1 establishes a protected control channel between the peers, itself governed by an IKE SA, and Phase 2 uses that channel to negotiate the IPsec SA that protects the actual data traffic.

Types of security associations

Two SAs govern every IPsec session. The IKE SA, established in Phase 1, protects the negotiation channel: the peers authenticate each other and agree on parameters for everything that follows. The IPsec SA, established in Phase 2, one per direction, actually encrypts and authenticates data traffic; it is shorter-lived and rekeyed more often than the IKE SA that spawned it.

SAs also differ by protocol. An ESP SA covers Encapsulating Security Payload traffic – encryption plus authentication, and the large majority of deployed IPsec – while an AH SA covers Authentication Header traffic, authenticating packets without encrypting them; it sees little use today since it cannot traverse NAT.

A minority of deployments use manually keyed SAs, with static keys instead of IKE negotiation. Manual SAs skip the control plane entirely, simplifying lab troubleshooting, but they sacrifice rekeying and Perfect Forward Secrecy, so production deployments avoid them.

Security Associations & Versa

VOS devices expose SA state for operational visibility. In Director, the Monitor tab’s device Services view includes a dedicated IPsec section with IKE Security Association and IPsec Security Association tabs – letting an operator drill into the live keys, algorithms, and remaining lifetime for a tunnel’s SAs, not just its up-or-down status. The same views are available through Titan Portal’s live monitoring dashboard.

SA visibility is also part of validating integrations. When connecting a VOS branch to Netskope Security Cloud over a site-to-site IPsec tunnel, Versa’s documented procedure checks IKE History, IKE Security Association, IPsec History, and IPsec Security Association in sequence – confirming valid SAs in both directions.

Frequently asked questions

What is the difference between an IKE SA and an IPsec SA?

An IKE SA protects the control channel peers use to negotiate – it authenticates them and secures further negotiation. An IPsec SA, negotiated inside that channel, actually encrypts and authenticates data traffic. Every tunnel has one IKE SA and at least two IPsec SAs, one per direction.

How many SAs does one IPsec tunnel need?

At minimum three: one IKE SA for the control channel, plus one inbound and one outbound IPsec SA for data traffic, since each SA is unidirectional. A tunnel carrying both ESP and AH traffic can maintain additional SA pairs beyond that minimum.

What happens when a security association expires?

Traffic protected by that SA stops being forwarded. In practice this rarely happens: IKE tracks each SA’s remaining lifetime and renegotiates a replacement well before expiry, so a healthy tunnel rekeys continuously in the background without any visible interruption to traffic.

What is a Security Parameter Index (SPI)?

A 32-bit value that identifies a specific SA. The sending endpoint stamps its SPI on every packet; the receiver combines that SPI with the destination address and security protocol to look up the matching SA and apply the correct keys and algorithms.

Can a security association be configured manually instead of negotiated?

Yes – a manually keyed SA uses administrator-configured static keys instead of IKE negotiation, skipping the control plane entirely. It is occasionally used for lab testing or troubleshooting, but production deployments avoid it because manual SAs cannot rekey automatically or provide Perfect Forward Secrecy.

More on Security Associations

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about security associations, these are worth looking at next.