F5 BIG-IP support for Canadian estates, from the upgrade you deferred to the exposure you inherited.
One Canadian team inventories the estate, closes the exposure, and runs the upgrades. BIG-IP LTM, Advanced WAF and BIG-IP APM each carry their own config, their own risk, and their own reason an upgrade keeps getting deferred.
Version, module set, hardware generation and management exposure, per device, before anybody touches a config. We check reachability from outside your network instead of trusting the documentation, and the answer is routinely different from what the network diagram claims.
A stolen list of undisclosed vulnerabilities turns an internet-facing management interface into a countdown. We get those interfaces off the public internet, separate administrative access from everyday access, and remove the accounts nobody recognises. CISA gave federal agencies until 2025-10-22 to do the same three things.
The platform you were told to wait for stopped being sold on 2026-01-01, so the F5 upgrade you deferred lands on the TMOS 17.x line you already run. Paired devices move one at a time, with the iRules read first and a rehearsed rollback staged behind each step.
Attackers held F5's own list of undisclosed vulnerabilities for a year before anybody outside knew, which changes what a patched BIG-IP LTM pair is actually worth.
IN PRODUCTION
We'd parked two upgrades for eighteen months because we were told the next platform was coming. SMEnode showed us the notice saying it wasn't, inventoried forty devices in a week, and found three with management interfaces reachable from outside. Those closed that day. The upgrades ran on the line that's still supported.
Two things happened to this platform inside twelve months, and most estates we see have reacted to neither.
F5 spent years telling customers the future was a rebuilt platform, then in August 2025 said it would stop developing BIG-IP Next and modernise the classic TMOS software instead (source: F5, K000152956). Release 20.3 was the final one, it reached end of life on 2025-04-30, and every Next part number stopped being sold on 2026-01-01. F5's own reason was that customers had told it re-platforming meant significant reintegration and recertification work. So if you deferred an F5 upgrade waiting for that migration, the wait is over: the answer is the software you already run, on the 17.x line, with a further major release promised after it. F5 NGINX is a separate product line on its own release train, so we scope it on its own rather than folding it into a BIG-IP plan.
The second thing was a breach, and it reframes maintenance rather than adding a task. F5 disclosed that attackers had been inside its own systems for at least a year, taking files from the BIG-IP product development environment that held some source code along with details of vulnerabilities that had not been published. CISA issued Emergency Directive ED 26-01 and gave federal agencies a week to inventory every F5 device, check whether management interfaces were reachable from the internet, and patch (source: CISA, ED 26-01). The uncomfortable part is what that implies: for a period, somebody outside F5 knew about weaknesses before the people running the boxes did. Patching stops being a project and becomes a standing discipline.
The management plane also stops being an internal convenience. Most Canadian estates we inventory have at least one device answering on its management interface from somewhere it shouldn't, usually because a rule was added during a migration and never removed. The other recurring finding is iRules nobody can explain, written by somebody who left, which is what makes an upgrade frightening. Reading them before the change rather than during the outage is most of what turns an F5 upgrade from an event into a maintenance window.
Four steps, and step 01 is a list rather than a change. We want every device with its software version, licensed modules, hardware generation and, most of all, whether anything outside your network can reach its management interface. Canadian estates that have been through two migrations rarely have that list, and building it is what turns the rest of the work from guesswork into a plan.
Every device with version, module set, hardware generation and management exposure, checked from outside rather than taken from documentation. You get a written position per device, not a rumour.
Management interfaces off the public internet, administrative access separated from everyday access, and the accounts nobody recognises removed.
Virtual servers, pools, profiles and iRules audited, including the ones nobody can explain, so an upgrade stops being a guess.
Paired devices moved one at a time onto a supported release with a rehearsed rollback, then a patch cadence somebody owns and a diary entry against the policy.
Answers first, including whether the replacement platform still exists and what the 2025 disclosure means for a device you already patched. An architect takes the call, not a salesperson.
LET'S CONNECT
A senior engineer replies within an hour, 24/7.