What’s New in F5 BIG-IP v21

F5 skipped three major version numbers, retired a whole product line, and shipped two releases in six months. Here is what BIG-IP v21.0 and v21.1 actually change, and what we recommend F5 customers do about it.

If you last upgraded to TMOS 17.1 and stopped paying attention, a lot has happened. In August 2025 F5 announced it was ending development of BIG-IP Next and putting that investment back into TMOS. In November 2025 the first result shipped as BIG-IP v21.0, and in May 2026 BIG-IP v21.1 followed as the long-term release most estates will standardise on. Between them they modernise the control plane, add first-class handling of AI traffic, introduce post-quantum TLS, and change the release cadence and hardware support you plan around.

Why the version number jumped from 17.5 to 21

Versions 18, 19 and 20 were never TMOS releases; they belonged to BIG-IP Next, F5's containerised rewrite. On 13 August 2025 F5 published a strategic update (MyF5 article K000152956) that discontinued BIG-IP Next – 20.3 was the final release – and committed to modernising TMOS instead, with continued investment in rSeries and VELOS hardware. BIG-IP Next for Kubernetes and the cloud-native network functions (CNF) for service providers continue as separate products. The next TMOS release took the number that made the lineage unambiguous: 21.

F5 pitches v21 as the first release of a modernised TMOS rather than a rebrand of 17.5, and the release notes back that up: the code base moved to 64-bit binaries, the configuration daemon became multithreaded, and the roadmap now targets the workloads that Next was supposed to own.

Two releases, two very different lifecycles

The cadence changed with v21 as well. Short-term stability releases now live for nine months instead of twelve, and long-term stability releases get a three-year Standard Support phase instead of four. That makes the choice between the two releases straightforward:

In practice: 21.0 was a preview of the new platform and has already reached end of support; 21.1 is the release to certify and deploy; and 17.1, still the most common version we see in production, has less than a year of development left. 17.5 remains a reasonable waypoint for platforms that cannot run 21.x yet.

Platform support: rSeries, VELOS and Virtual Edition only

BIG-IP 21.x does not run on iSeries or VIPRION, and vCMP guests are not supported. The supported targets are rSeries appliances and VELOS chassis running F5OS – where BIG-IP runs as a tenant – and Virtual Edition on the usual hypervisors and public clouds. Several 21.1 tenant features (per-port UDP round-robin disaggregation, Q-in-Q on VELOS) additionally require F5OS 2.0 or later.

Two smaller but important prerequisites: the move to 64-bit binaries means F5 asks you to verify free control-plane memory before upgrading (150 MB free for configurations under 10,000 objects, 250 MB above that), and iRules LX workspaces still on Node.js v0.12 must move to Node.js v6 – v0.12 support is removed in 21.1. Upgrades are supported from 15.0.0 or later, and 21.1 adds a validate option to tmsh load sys ucs … platform-migrate that previews the configuration changes a UCS will undergo when it lands on rSeries, VELOS or VE.

A modernised control plane

This is the heart of v21 and the reason the number changed.

• Multithreaded MCPD. The configuration daemon now processes query and statistics requests concurrently with configuration changes, using up to four worker threads (one by default). F5 quotes end-to-end configuration validation up to 25% faster in 21.0, and faster MCPD restarts.
• 64-bit configuration database. eXtremeDB moved to version 8.4 and 64-bit, with a shared-database mode for concurrent access. F5 now publishes scaling guidelines rather than leaving you to discover the limits: up to one million configuration objects overall, with 30,000 LTM objects, 10,000 virtual servers, 10,000 pools, 25,000 pool members, 1,000 iRules, 5,000 control-plane monitors and 25,000 in-TMM monitors as the documented ceilings.
• Configuration survives an MCPD restart. Unsaved changes now persist across a restart by default (a database variable restores the legacy load-from-files behaviour).
• iControl REST executes requests up to 10% faster in 21.1 and gains per-client rate limiting on the management endpoint – a welcome defence for a management plane that has featured in several critical CVEs.
• BigD goes multithreaded in 21.1, scaling to 15,000 control-plane monitors with the thread count derived from available vCPUs.
• Operational polish. In-place upgrades for selected engineering hotfixes with a dry-run mode, a designated primary admin account that need not be admin, better protection of MCPD from the kernel's out-of-memory killer, restjavad on Java 21, and a new web UI available as a beta behind a preference switch.

F5 also states that 21.0 carried the lowest total CVE count of any release to date and fixed more than 200 CVEs since 17.5.0.

AI traffic: MCP, agents and S3 data delivery

Most of the new functional capability is aimed at AI workloads, which is where F5 expects application delivery to grow.

• Model Context Protocol (MCP). 21.0 added traffic management for MCP – the protocol AI applications use to reach tools and data sources. 21.1 adds an aimcp persistence profile so a session's requests reach the same server, and Advanced WAF gains an MCP Protection policy template that inspects MCP traffic for the OWASP MCP Top 10: tool poisoning, prompt and tool injection, secret exposure and SSRF, with JWT validation and Data Guard. Response-side inspection is bypassed for streaming (SSE) responses.
• Agent-to-Agent (A2A). Experimental load balancing for A2A traffic in 21.1, with iRules-based logging; fuller management is promised for later releases.
• Dynamic Client Registration. Zero Trust Access (the module formerly marketed as APM) implements OAuth 2.0 Dynamic Client Registration (RFC 7591), so AI agents – or any client – can register programmatically with an initial access token instead of an administrator creating each client.
• S3 data delivery. 21.0 ships default TCP and Client SSL profiles tuned for S3 and S3-compatible object storage (F5 names MinIO, Dell, DDN, Pure Storage and NetApp) for high-throughput ingestion and retrieval by AI pipelines.

Post-quantum cryptography

21.1 is the first BIG-IP release with NIST-aligned post-quantum key exchange. Two hybrid cipher groups combine an elliptic-curve exchange with ML-KEM (FIPS 203): SecP256r1 + ML-KEM-768 and SecP384r1 + ML-KEM-1024, usable on client-side and server-side SSL profiles and in SSL forward proxy. The SSL VPN in Zero Trust Access gets its own quantum-resistant option, X25519 + ML-KEM-768; quantum-safe IPsec is promised later. In the same release, X25519 key exchange is hardware-accelerated on platforms with Intel QuickAssist, and new parent SSL profiles default to TLS 1.3 and DTLS 1.2.

If you run a regulated workload with a "harvest now, decrypt later" threat model, this is the reason to prioritise 21.1 over 17.5.

Certificates: ACMEv2 and the Entrust change

21.1 adds native ACMEv2 support for automated certificate issuance, renewal and deployment against Let's Encrypt, ZeroSSL, DigiCert, Buypass, Google Trust Services and SSL.com – something most estates have been scripting around for years. Separately, because browsers stopped trusting Entrust certificates issued after 12 November 2024 and the CA that BIG-IP used to reach F5 services expires in February 2026, 21.0 replaced the Entrust dependency with a custom F5 CA bundle. That change was backported to 17.1.3 and 17.5.1.2, so even estates staying on 17.x should pick it up.

Advanced WAF and API security

• OpenAPI 3.1 specifications can now be imported to build API security policies; 2.0 and 3.0 continue to work.
• HTTP/3 protection. WAF, bot defense and layer 7 DoS protections now cover client-side HTTP/3 (QUIC) traffic with the same signatures and violations as HTTP/1.1 and HTTP/2. Server-side HTTP/3 and behavioural DoS for HTTP/3 are still to come.
• MCP Protection policy template, described above.
• Splunk logging gains an extended key-value format with structured violation details.

SSL Orchestrator

21.0 made client SNI preservation the default for Inbound Gateway topologies (existing topologies need a redeploy to pick it up) and extended iRules to both sides of an inspection service, so header enrichment – injecting an authenticated user identity, say – no longer needs custom scripting. SSL Orchestrator 14, which ships with 21.1, adds policy-based dynamic egress routing inside a single topology, raises the limit from 8 to 50 devices per L2 inspection service, adds inspection-service persistence (source, destination, hash, host, SSL and universal), supports transparent HTTP profiles for non-compliant sites, and adds Cryptocurrency and Crypto Mining URL categories.

Zero Trust Access (APM)

• Native IPsec VPN tunnels for the Windows Edge Client and F5 Access on macOS, generated from a connectivity profile and authenticated with machine certificates – the first real alternative to SSL VPN on the platform.
• Native SAML for the Edge Client using the system browser, which unlocks FIDO2 and Microsoft Entra ID device authentication without the iRule workarounds many of us have deployed.
• HTTP Connector in per-session policies, so a session can consult an external service before it is established.
• Quality-of-life items: locked-client exclusions beyond the old limit of ten, larger OAuth claims, selectable Edge Client log levels, automatic Machine Tunnel service upgrades, endpoint inspection on Ubuntu ARM64, and Portal Access rewriting that understands ES13 JavaScript.

DNS and LTM details worth knowing

• Multiple response policy zones per DNS cache in 21.1 – up to 65,535 feeds with configurable precedence, TSIG-secured transfers and a full set of policy actions – replacing the single-RPZ limitation. 21.0 added Extended DNS Errors in forwarding scenarios and a variable controlling DNS64 behaviour on NXDOMAIN.
• In-TMM monitors can source from SNAT pools, which finally makes outbound virtual servers with customer-side pools monitorable the way they are routed.
• MAC-based health checks via ARP for devices that should be validated at layer 2.
• C3D (client certificate constrained delegation) gains certificate caching, lifespan control and extension handling through new iRule commands, and the OCSP nonce becomes configurable for responders that cannot handle it.

F5OS and tenants

21.1 tenants on VELOS and rSeries accept cloud-init user data at first boot – passwords, users, SSH keys and Declarative Onboarding or AS3 declarations – which makes zero-touch tenant provisioning practical. Per-port UDP round-robin disaggregation and Q-in-Q on VELOS arrive alongside F5OS 2.0.

Automation: AS3 today, a new declarative API tomorrow

The most consequential change for automated estates is still in alpha. 21.1 introduces a new declarative API, integrated into TMOS rather than installed as an extension, with per-application lifecycle management and near-real-time deployment – positioned as the successor to AS3. AS3 and Declarative Onboarding remain the supported path today, and BIG-IQ 8.4.1 is the management release aligned with v21. Our advice is to keep building on AS3 and to structure declarations per application now, so the eventual move is a format change rather than a redesign.

What we recommend

• Plan the 17.1 exit now. 17.1 leaves software development on 31 March 2027. Certify 21.1 in your lab this year; treat 17.5 as the fallback only for platforms that cannot run 21.x.
• Do not deploy 21.0 in production. It was a nine-month release and is already out of support.
• Refresh iSeries and VIPRION. 21.x will not run on them. Sizing rSeries or VELOS tenants – and using the 21.1 UCS validation to preview the platform migration – belongs in the same project.
• Check memory and iRules LX before upgrading. The 64-bit control plane needs headroom, and Node.js v0.12 workspaces stop working.
• Take the CA bundle change even if you stay on 17.x (17.1.3 or 17.5.1.2) so devices can keep reaching F5 services after the Entrust expiry.
• Pilot post-quantum TLS on a client-facing virtual server if you carry long-lived sensitive data, and re-baseline TLS performance with the new defaults.
• If you are fronting AI applications, look at MCP persistence and the MCP Protection template before you build the same controls in an API gateway.

JustADC runs release certifications, platform migrations and 21.1 upgrades as fixed-scope engagements – see Certify Releases and Migrate & Upgrade, or talk to us about your estate.

Sources

• F5 blog: BIG-IP v21.0 – control plane, AI data delivery and security enhancements (18 November 2025)
• DevCentral: What's new in BIG-IP v21.0?
• BIG-IP 21.0.0 release notes: new features
• F5 blog: BIG-IP v21.1 is now generally available (6 May 2026)
• DevCentral: What's new in BIG-IP v21.1?
• BIG-IP 21.1.0 release notes: new features
• K5903: BIG-IP software support policy (release dates and lifecycle)
• K000152956: BIG-IP strategic update – modernizing BIG-IP TMOS and discontinuing BIG-IP Next

About the Author

Silvano Da Ros is an F5 ASM and APM certified Architect for JustADC, with over 15 years experience with various ADC vendors. When he’s not designing and troubleshooting F5 environments, you can find him on the tennis court or spending time with family.

Feel free to contact us to plan your BIG-IP 21.1 certification and upgrade.