What is a Preshared Key?

A preshared key (PSK) is a secret string manually configured on both ends of an IKE or IPsec connection so each peer can prove its identity to the other. It is the simplest IKE authentication method – no certificate authority, no enrollment, just a matching string both sides already know.

Key takeaways

• A PSK is a shared secret that authenticates both ends of an IKE tunnel.
• It’s the simplest alternative to certificate-based (PKI) authentication.
• Both peers must configure the identical key, or negotiation fails outright.
• PSKs suit small or ad hoc links; certificates scale better across fleets.
• Versa PSK fields reject several special characters – safest to avoid " < > # / { }.

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

Why is a PSK important?

Every IKE tunnel – the control channel behind an IPsec VPN – has to answer one question before it moves any traffic: is the device on the other end who it claims to be? A PSK answers that with the cheapest possible mechanism: a secret both sides already hold. No certificate authority, no enrollment, no lifecycle to manage – which makes PSKs the fastest way to bring up a tunnel, and why they remain common for links to third-party gateways, lab builds, and connections where a PKI is disproportionate to the need.

The tradeoff is operational, not cryptographic: a PSK is a static secret distributed and rotated by hand, and a leak exposes every tunnel sharing it until someone rotates the key everywhere. Knowing when a PSK is the right call – and when a certificate is worth the setup cost – is a basic decision in any VPN or SD-WAN deployment.

What is a PSK?

A PSK is configured as part of an IKE peer’s authentication settings on both ends of a tunnel: each side presents its key (usually the same string, though asymmetric local/peer keys are possible), and IKE derives keying material that proves each peer holds the secret – without sending the key itself across the wire. This happens during IKE’s authentication exchange, before the IPsec security association that protects data traffic is established.

Because the key is symmetric, both administrators must enter exactly the same string, or the exchange fails outright with no partial credit. PSKs work with both IKEv1 and IKEv2, and are typically paired with an identity type – an IP address, FQDN, or email string – identifying which key to check.

Types of PSK deployment

Per-peer (unique) PSK assigns a distinct key to each tunnel or device pair – the stronger pattern, since compromising one key exposes only one connection, at the cost of tracking more secrets. Group (shared) PSK reuses one key across many devices, faster to roll out but riskier: a single leak compromises every peer using it – a common tradeoff during staging or bulk onboarding, later replaced by unique keys or certificates. Site-to-site PSK authenticates a fixed, long-lived tunnel between two gateways. Remote-access PSK authenticates a client-initiated tunnel, and is often layered with a user-level method like EAP, since a device-level secret alone doesn’t identify the human behind it.

PSK & Versa

VOS devices support PSK as one of two IKE authentication methods, alongside certificates, configurable independently for local and peer authentication in an IPsec VPN profile‘s IKE tab. Each side pairs its key with an identity type – email, FQDN, or IP – and the field rejects certain special characters. Versa’s profile documentation is not fully consistent on the set: its prose names " < > # /, while its special-character table also marks { } as not allowed – and, conflictingly, marks / as allowed. Until that is reconciled upstream, generate keys that avoid all eight (" < > # / { }). PSK authentication also appears at the site-to-site tunnel level for peer types such as AWS Transit Gateway, Azure Virtual WAN, Zscaler, and Versa Director–managed tunnels, where primary and secondary tunnel keys can be entered directly or deferred to per-device bind data at deploy time. During initial device staging, an organization’s IKE authentication mode – PSK or PKI – determines how branch devices first authenticate to the Controller, making it one of the earliest decisions in a deployment.

Frequently asked questions

What is the difference between a PSK and a certificate for IKE authentication?

A PSK is a shared secret both peers already hold; a certificate is signed by a trusted CA, proving identity without exposing a shared string. Certificates scale and rotate more safely across large fleets; PSKs are faster to configure for small deployments.

Is a PSK secure enough for production VPNs?

A long, random, unique-per-tunnel PSK is cryptographically sound, but the operational risk is distribution and rotation at scale – a leaked or reused key compromises every tunnel sharing it. Many deployments use PSKs for staging or small links and certificates for the broader fleet.

What characters are not allowed in a PSK?

Avoid eight characters: quotation mark, angle brackets, hash sign, forward slash, backslash, and braces – " < > # / { }. Versa’s own documentation disagrees with itself on the forward slash (its prose forbids it, its character table allows it), so the safe practice is to exclude it. Letters, numbers, and most other characters are permitted.

Can I use a PSK for some tunnels and certificates for others?

Yes. Authentication method is set per IPsec VPN profile, and local and peer authentication can even use different methods within one profile, so an organization can mix PSK- and certificate-authenticated tunnels as needed.

What happens if the PSK doesn’t match on both ends?

IKE authentication fails and the tunnel never establishes – no security association forms, so no traffic passes. There’s no partial match; the configured strings must be identical (subject to asymmetric local/peer key setups) on both peers.

More on PSK

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

Related terms

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