If you have ever tried to stand up a site-to-site tunnel between an ASA running 9.8 code and a newer FTD box on 7.4, and watched Phase 1 fail for no obvious reason, you already know why this post exists. Cisco has quietly rewritten the encryption and Diffie-Hellman story on its firewall platforms several times over the last decade, and the documentation for any single release only ever tells you what that release supports, not what changed to get there or what is coming next.

This guide pulls together the IKEv1 and IKEv2 support history, the encryption algorithms and DH groups available at each stage, and the hardware platforms involved, for both classic ASA software and Firepower Threat Defense (FTD). Every version-specific claim below is backed by a Cisco source, and where Cisco’s own documentation contradicts itself (it does, more than once), that is called out explicitly rather than papered over.

Two Operating Systems, One Hardware Lineage

Before getting into ciphers, it helps to be clear on what is actually running where, because ASA and FTD are two different software images that frequently share the same box.

ASA (Adaptive Security Appliance) is Cisco’s original firewall operating system: a mature, CLI-first, stateful firewall and VPN concentrator that has been shipping since the early 2000s.

FTD (Firepower Threat Defense) is the unified image that merges the ASA data plane with the Sourcefire/Snort inspection engine, managed either by Firepower/Secure Firewall Management Center (FMC) or locally through Firepower Device Manager (FDM). FTD first appeared as a distinct product around the 6.0 release.

A point that trips people up during platform planning: almost every current Firepower and Secure Firewall appliance is dual-OS. The Firepower 1000, 2100, and 4100 series, the Firepower 9300 chassis, and the newer Secure Firewall 1200, 3100, 4200, and 6100 series can all run either ASA software or FTD software, per Cisco’s ASA/FTD reimage guide and compatibility matrix. On the 4100 and 9300 chassis, ASA and FTD are deployed as logical devices under FXOS rather than through a simple reimage, but the same physical hardware supports both operating systems. There is no current Cisco firewall appliance that is contractually locked to FTD only.

Cisco has also been rebranding the hardware line gradually rather than all at once. “Firepower” covers everything released from roughly 2016 through 2020 (Firepower 1000, 2100, 4100, and 9300). Starting with the Secure Firewall 3100 series in April 2022, new hardware has shipped under the “Secure Firewall” name, a naming convention that now also covers the 4200 (2023), 1200 (2024/2025), and 6100 (2025) series. In March 2025, Cisco updated CLI and device-output display strings on newer platforms to read “Cisco Secure Firewall” instead of “Firepower,” but this was a cosmetic change with no functional effect, and older Firepower 1000/1100, 4100, and 9300 hardware still shows “Firepower” branding in places. The virtual products were renamed too: ASAv became “Secure Firewall ASA Virtual” and FTDv became “Secure Firewall Threat Defense Virtual,” though most engineers still just say ASAv and FTDv.

IKEv1 and IKEv2 on Cisco ASA

History

IKEv1 (configured as ISAKMP on ASA) goes back to the very first ASA software releases, with the crypto isakmp policy command documented in the command reference as far back as ASA 7.0(1).

IKEv2 support arrived considerably later. Every Cisco configuration example for ASA IKEv2 site-to-site tunnels anchors the feature to “ASA software version 8.4(1) or later,” which is the best-supported answer for when IKEv2 was introduced, even though Cisco’s release-by-release feature roadmap page did not render cleanly enough during research to pull a single direct quote confirming the exact bullet. Every hands-on configuration guide Cisco publishes for IKEv2 on ASA, however, consistently gates the feature at 8.4(1).

Current status: both protocols are still supported

As of the current ASA 9.x documentation set, IKEv1 has not been deprecated or removed from ASA. A Cisco Community discussion states plainly that “all ASA versions support IKEv1” and that it is “not yet deprecated.” It is worth separating this from the IETF’s RFC 9395, “Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms,” published in 2023. RFC 9395 is an industry-wide recommendation from the IETF, not a Cisco ASA product announcement, and there is no Cisco ASA release note or field notice that cites it or announces IKEv1’s removal from ASA. What Cisco has actually removed is a set of specific weak algorithms inside IKEv1 and IKEv2 policy, covered below, not the protocols themselves.

Command syntax differences

The two protocols use separate, non-interchangeable configuration objects on ASA:

IKEv1 (Phase 1 / ISAKMP policy):

crypto ikev1 policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 14
 lifetime 86400

IKEv2 policy:

crypto ikev2 policy 10
 encryption aes-256
 integrity sha512
 group 21
 prf sha512
 lifetime seconds 86400

The meaningful structural difference is that IKEv2 splits the old IKEv1 hash keyword into two distinct roles: integrity, which authenticates the security association, and prf (pseudo-random function), which derives keying material. IKEv1 does not distinguish between the two. ASA’s IKEv2 implementation also folds policy and proposal into a single crypto ikev2 policy statement, unlike the separate proposal/policy objects used in IOS FlexVPN.

Encryption algorithms and DH groups, by era

Baseline (ASA up through roughly 9.14): IKEv1 and IKEv2 policy both supported DES (56-bit), 3DES (168-bit, the long-time default), AES-128, AES-192, and AES-256 for encryption; MD5 and SHA-1 for hash; and DH groups 1 (768-bit), 2 (1024-bit, the long-time default), and 5 (1536-bit). DH group 7, aimed at low-power/PDA clients, was deprecated back in ASA 8.0(4) in favor of group 5.

The turning point: ASA 9.15(1). Cisco’s release notes for 9.15(1), under “Low-Security Cipher Removal,” are explicit and specific. Diffie-Hellman groups 2 and 24 were removed. Encryption algorithms DES, 3DES, AES-GMAC, AES-GMAC-192, AES-GMAC-256, NULL, ESP-3DES, ESP-DES, and ESP-MD5-HMAC were removed. MD5 was removed as a hash algorithm. For crypto ikev1 policy, the specific removed subcommands were hash md5, encryption 3des, encryption des, and group 2. For crypto ikev2 policy, the removed subcommands were prf md5, integrity md5, group 2, group 24, encryption 3des, encryption des, and encryption null. Cisco’s notes warn that any configuration still referencing these values will be rejected outright on upgrade to 9.15(1) or later, and that this is especially disruptive for clustering and failover pairs where the peer’s config must match. If you are still running pre-9.15 code anywhere in your environment, this is the release that will break your VPN configuration on upgrade if you have not already migrated off DES, 3DES, MD5, or DH groups 2 and 24.

A separate, easily confused removal in ASA 9.16(1): the ssl dh-group command (used for TLS/DTLS on the clientless portal and AnyConnect SSL, not IKE) also had groups 2, 5, and 24 removed in 9.16(1), replaced by group 15 for SSL DH and group 31 for IPsec. This is a different command in a different context from the IKE removal above, and it is easy to conflate the two when skimming release notes, but they are distinct changes on distinct features.

Current ASA documentation (9.16 through 9.18): the IKEv1 policy table in the current CLI configuration guide only documents Group 14 as a configurable option, with no mention of groups 1, 2, or 5 at all. For IKEv2 policy, the same guide lists groups 14 (default), 19, 20, 21, and 24.

Current IKEv1 encryption options are AES (default), AES-192, and AES-256, with hash limited to SHA (SHA-1). Current IKEv2 encryption options are AES, AES-192, AES-256, AES-GCM, AES-GCM-192, AES-GCM-256, and NULL (permitted only alongside AES-GCM). Integrity options are SHA-1 (default), SHA256, SHA384, SHA512, and NULL (with AES-GCM only). PRF options mirror the integrity list: SHA, SHA256, SHA384, SHA512.

Next Generation Encryption (NGE) and Suite B

ASA 9.0 is the release that introduced Suite B / Next Generation Encryption support, per Cisco’s own ASA 9.0 data sheet, which lists “Suite-B set of cryptographic algorithms including Elliptical Curve, SHA-2 (256, 384 and 512-bit hashes)” alongside IPsecv3/ESPv3 enhancements. That same data sheet scopes NGE/Suite B support to the ASA 5500-X series and ASA 5585-X appliances specifically. A Cisco Community knowledge base article (not an official doc, but detailed) adds that NGE is fully supported on the 5585-X, 5500-X series, and 5580, with only partial support on the older non-X 5505/5510/5520/5540/5550 due to hardware limitations, and notes that ASDM on older platforms may only display groups 1, 2, and 5 in the GUI even when newer groups are configurable via CLI. Treat the exact platform list as reasonably well corroborated but not perfectly reconciled between the official data sheet and the community source.

FIPS 140 and Common Criteria

ASA has a long history of FIPS 140-2 validations tied to specific firmware builds, and the newest platforms have moved to FIPS 140-3. A representative sample of NIST CMVP certificates:

The 140-3 security policy for ASA 9.20 on the Secure Firewall 3100 series lists AES-CBC and AES-GCM (128/192/256) as the approved symmetric ciphers, with key-exchange groups named using their IETF equivalents: ffdhe2048, ffdhe3072, ffdhe4096, modp-2048, modp-3072, and modp-4096 (the same underlying math as classic DH groups 14, 15, and 16). Notably, 3DES does not appear in that approved list at all, which lines up with its general removal from ASA VPN configuration starting in 9.15(1). The elliptic-curve groups 19, 20, and 21 are not explicitly enumerated in the excerpt of that 140-3 policy reviewed for this post, which leaves an open question about their FIPS-approved-mode status worth confirming directly if FIPS mode plus ECDH is a hard requirement for your deployment.

Cisco also maintains NIAP/Common Criteria Security Target documents for ASA 9.20 on the Firepower 4100/9300 chassis, on the Secure Firewall 3100 series, and on Firepower 1000/2100 hardware. These are hosted on the Common Criteria and NIAP evaluation-scheme sites rather than cisco.com, and CC-specific algorithm restrictions (which typically mirror NDcPP requirements: AES-GCM/CBC, SHA-2, DH groups 14 and above, no DES/3DES/MD5/SHA-1) are worth pulling directly from those Security Target PDFs if Common Criteria compliance drives your configuration.

IKEv1 and IKEv2 on FTD (FMC and FDM)

History

Native site-to-site VPN for FTD arrived earlier than a lot of engineers assume. FTD/FMC 6.1.0’s release notes state directly, under “New Features for Version 6.1: Core Firewall Features”: “The ability to create a site-to-site VPN between Firepower NGFW devices is now enabled, allowing you to connect branch offices/campus firewalls using a secure tunnel. Both Internet Key Exchange v1 and v2 (IKEv1 and IKEv2) protocols, as well as static and dynamic tunnels, are supported.” By 6.2.x, site-to-site VPN had matured into its own chapter of the FMC configuration guide with all three policy-based topology types (point-to-point, hub-and-spoke, and full mesh) explicitly documented. Site-to-site VPN is not supported in clustered FTD deployments, a caveat that has carried through every version reviewed.

Remote access VPN (AnyConnect) support came a release later, introduced in FTD 6.2.2, and it has always been IKEv2 plus SSL/TLS only. Every version of the FMC RA VPN configuration guide checked for this post (6.2.3, 6.6, 7.0, 7.1, 7.2) titles the relevant task “Configure Remote Access VPN IPsec/IKEv2 Parameters,” with no IKEv1 option ever exposed for RA VPN.

Route-based site-to-site VPN using static VTIs (Virtual Tunnel Interfaces) was validated and documented against FMC/FTD 6.7.0. Dynamic VTI (DVTI) came later still, introduced in FTD 7.3, and per Cisco’s documentation, “VPN sessions using DVTIs only support IKEv2.”

Current status: IKEv1 is still available for policy-based site-to-site VPN

As of the current FMC and FDM documentation (checked through 7.1, 7.4, and 7.6), IKEv1 has not been removed from FTD. The FMC device configuration guide for site-to-site VPN still reads: “Choose the IKE versions to use during IKE negotiations. Check the IKEv1 or IKEv2 check box. Default is IKEv2. Select either or both options as appropriate.” Static VTI explicitly supports both IKE versions. FDM (on-box, no FMC required) also still exposes both IKEv1 and IKEv2 for policy-based site-to-site connections, with a restriction to one protocol only for route-based connections. What has changed is not the availability of IKEv1 itself, but a set of weak algorithms within it, covered in the next section.

One planning note for anyone hoping to use FlexConfig to work around a GUI limitation: current FMC documentation (7.0 through 7.6) explicitly lists the entire VPN configuration category as blocked in FlexConfig. FlexConfig is intended for features not yet exposed through native policy, not a general escape hatch for extra cipher options, and Cisco’s own guidance says to use it “only if you are an advanced user with a strong ASA background and at your own risk.” Narrow, point-in-time exceptions exist (Cisco has published a FlexConfig workaround for VPN idle-timeout, a group-policy attribute not otherwise exposed in the GUI at the time), but there is no documented general mechanism for adding IKEv1 ciphers beyond what the FMC or FDM interface exposes.

Encryption algorithms and DH groups, by era

FTD 6.1 through 6.6: IKEv1 and IKEv2 policy both supported DH groups 1, 2, 5, 14, 19, 20, 21, and 24, along with DES, 3DES, AES, AES-192, AES-256, and AES-GCM (IKEv2 only) for encryption, and MD5, SHA-1, SHA256, SHA384, and SHA512 for hash/integrity. For IKEv2, PRF used the same algorithm list as the hash/integrity setting.

The turning point: FTD 6.7.0. Cisco’s documentation on deprecated and removed ciphers is specific: Diffie-Hellman group 5 was deprecated for IKEv1 and IKEv2, groups 2 and 24 were removed outright, and the encryption algorithms 3DES, AES-GMAC, AES-GMAC-192, and AES-GMAC-256 were removed. DES was not removed, but Cisco’s own note narrows its use sharply: “DES continues to be supported in evaluation mode or for users who do not satisfy export controls for strong encryption.” In practice, for anyone running standard export-compliant licensing, DES is not a real option either.

Current FTD documentation (7.0 through 7.6, and the newly numbered 10.0 release): the supported DH group list has grown to include groups 14, 15, 16, 19, 20, 21, and 31 (Curve25519, a 256-bit elliptic-curve group). Group 24 does not reappear. The exact minor release where groups 15, 16, and 31 were first added was not pinned down precisely during research; it falls somewhere between 6.7 (where they are absent) and 7.0/7.4 (where they are present), and is worth a direct release-notes check if you need the exact cutover for a compliance document. Current FMC guidance for NSA Suite B compliance recommends IKEv2 with one of the elliptic-curve groups: 19, 20, or 21.

A quick word on FTD version numbering

Cisco restarted its Secure Firewall version numbering in 2026: “Release 10.0 is live,” per Cisco’s own release documentation, describing it as an expansion of the improvements introduced in 7.6 with new features layered on top. As of this writing, Cisco’s currently “Suggested” (most broadly recommended for production) release remains 7.6.4, even with 10.0 available, so do not assume 10.0 is automatically the right target for a new deployment. Notable 10.0 site-to-site VPN features include SGT metadata preservation across VTI tunnels, ECMP load balancing across dynamic-VTI hubs, BFD-based failover for site-to-site VPN, and distributed site-to-site VPN with clustering on the Secure Firewall 4200. None of these are cryptographic algorithm changes; the DH group and encryption support described above has been stable since the FTD 7.0 to 7.6 timeframe.

Next Generation Encryption and Suite B Guidance, Summarized

Cisco’s own Next Generation Cryptography guidance sorts algorithms into three practical tiers, and it applies equally to ASA and FTD deployments:

Worth noting: Cisco’s own product-level removals have moved considerably faster than this guidance’s “legacy” framing would suggest. 3DES is fully removed from both ASA (9.15(1)+) and FTD (6.7+), not merely discouraged, and DH group 2 is removed from both platforms as well. Group 1 remains an interesting gap: no removal notice for group 1 specifically was found for either ASA or FTD, only the general NGE guidance to avoid it, so it is worth testing directly against your current code rather than assuming it has been removed. SHA-1 and MD5 similarly remain configurable as IKE hash/integrity/PRF options on both platforms as of current documentation (aside from the specific MD5 removal from IKE policy on ASA 9.15(1) and FTD noted above), with no official removal timeline published for the SHA-1 option specifically.

Post-Quantum Cryptography: What’s Actually Coming

For anyone doing multi-year VPN architecture planning, Cisco published a dedicated Secure Firewall post-quantum cryptography roadmap in April 2026 that names ASA and FTD directly (not a generic “some products may support this” statement):

• RFC 8784 (Postquantum Preshared Keys for IKEv2) has been available on ASA since version 9.18.
• RFC 9242 and RFC 9370 (IKEv2 hybrid/multiple key exchanges, letting a classical and post-quantum key exchange run side by side in the same negotiation) have been available on ASA since version 9.19.
• ML-KEM (FIPS 203), the NIST-standardized replacement for ECDH key agreement (the standardized form of what was known as Kyber during the NIST competition), is targeted to arrive in Secure Firewall Threat Defense 10.5 and ASA 9.25, with general availability targeted for late 2026.
• SKIP (Cisco’s own Secure Key Integration Protocol) and PQC-capable TLS decryption are targeted for the same FTD 10.5 release.
• ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), post-quantum signature schemes replacing RSA/ECDSA authentication and offering a hash-based signature alternative respectively, are planned for FTD/ASA 11.0, targeted for the second half of 2027, along with remote-access VPN PQC support and PQC support for management-plane access.

If you are running ASA 9.18 or later today, you already have the building blocks (RFC 8784 preshared-key mixing) to add a quantum-resistant layer to an existing IKEv2 tunnel without waiting for ML-KEM. It is a preshared-key mechanism layered on top of the existing key exchange, not a full post-quantum key exchange, but it is real, available today, and worth using on anything carrying sensitive long-lived traffic.

Platform Lineup: What’s Actually Sold and Supported in 2026

ASA-only hardware (cannot run FTD)

Dual-OS hardware (runs ASA or FTD)

Virtual

ASAv (Secure Firewall ASA Virtual) and FTDv (Secure Firewall Threat Defense Virtual) are both actively sold, offered in a range of vCPU/throughput tiers from the smallest lab-sized instance up to an unlimited-throughput tier, and run on the standard hypervisor and cloud targets (VMware, KVM, Hyper-V, OpenStack, Nutanix for FTDv, plus AWS, Azure, GCP, OCI, and Alibaba Cloud). Current release train for both is 9.24(1)/FTD equivalent.

No specific Cisco documentation was found stating that encryption algorithm or DH group availability differs by hardware platform. The IKEv1/IKEv2 policy option lists in FMC, FDM, and ASA CLI/ASDM appear to be entirely software (version)-driven rather than hardware-gated. Where hardware does matter is IPsec throughput: platforms with a dedicated crypto accelerator (the 4100/9300 chassis, per informal reports) process IPsec meaningfully faster than smaller platforms without one (reports point to the Firepower 2100 series lacking hardware crypto acceleration), but this is a performance distinction, not a difference in which ciphers or groups you can select.

What to Actually Configure Today

Pulling all of the above into a practical recommendation, for both new ASA and new FTD deployments in 2026:

• Use IKEv2 wherever the far-end peer supports it. IKEv1 is still functional and not deprecated by Cisco, but it lacks the PRF/integrity separation, has a smaller set of currently-supported DH groups on ASA (Group 14 only, per current documentation), and there is no reason to choose it for a new tunnel.
• Encryption: AES-GCM-256 if both ends support it (combined cipher, no separate integrity algorithm needed), or AES-256 with a separate SHA-384/512 integrity algorithm if GCM is not available.
• Diffie-Hellman group: 20 or 21 for NGE/Suite B alignment, or group 14 as a safe, universally-supported classical fallback. Do not configure group 24 on ASA even though it may still appear in a configuration guide table; it was removed from working configuration in 9.15(1). Groups 1, 2, 5, and 24 should all be considered retired at this point across both platforms.
• PRF/integrity: SHA-384 or SHA-512. Do not use MD5 or SHA-1 on any new configuration, even though both remain technically configurable on current code with no published removal date.
• If you are carrying long-lived, highly sensitive traffic over IKEv2 tunnels on ASA 9.18 or later today, add RFC 8784 postquantum preshared-key mixing now rather than waiting for the full ML-KEM implementation targeted for late 2026.