In the branch you did not buy a firewall: you bought an SD-WAN checkbox

If any of your sites runs a VeloCloud Edge with the Fortinet, Palo Alto or Check Point firewall inside it, that checkbox in the orchestrator has a date on it: 28 February 2027. And what expires is not a licence. It is the idea that the branch firewall was ever yours.

The notice is dated 15 May 2026 and it is called "End of Availability for VeloCloud Security VNF Services". It says the Security VNF feature in the SD-WAN software is entering the final phase of its lifecycle, and it names all three: "Checkpoint Firewall, Fortinet Firewall and Palo Alto Networks Firewall through the SD-WAN subscription service offerings". It also says "5.2.x will be the last limited supported version for VNF" — limited support meaning critical fixes only, no new features — and that the last day of 24x7 technical support and end-of-support land on the same spot: 28 February 2027. The path the vendor recommends is Enhanced Firewall Services.

Four months on, nothing has happened in the branch. The boxes are still up, the firewall is still filtering and nobody has noticed a thing. Which is exactly why it is worth looking at now, while it is still a decision and not a maintenance window in a hurry.

What was inside that box

The design was elegant, which is why it sold well. The branch Edge did not just move packets: it spun up a virtual machine inside itself running your vendor's firewall, and traffic was steered into it. In the orchestrator you picked the brand from a list and, in Fortinet's case, even the number of cores, because the VM licence depended on the cores you assigned; and you pasted the licence in yourself, into a text box. The policy was still yours, written in the console you already knew, with your objects and your exceptions.

What people were buying there was one less box in a wall cabinet, one less contract and one less site visit. In a shop with five staff and a cabinet that shares space with the brooms, that is worth real money.

What arrives in its place is not the same thing, and that deserves saying without drama

The Edge already shipped a firewall of its own: the documentation describes it as "stateful inspection along with application identification". What Enhanced Firewall Services adds is the layer above: URL category filtering, URL reputation filtering, malicious IP filtering and IDS/IPS. The feature list lives in the administration guide; the design guide explains how it works underneath, and that matters because it defines what you are tying yourself to: "The Edge employs a Suricata solution for IDPS engine and signatures", the signatures are curated and verified by the vendor, and "the Orchestrator queries the VeloCloud Threat Intelligence cloud every 4 hours".

It is a reasonable product. For many branches it covers more than what was actually switched on in the VNF, which very often ends up being a policy copied from head office with two rules tweaked — our impression, not a measurement. It remains, mind you, their firewall and not yours. And that difference does not show up the day you turn it on. It shows up the day somebody asks why something got blocked.

The bill nobody budgets for is not the licence

The licence part is clear and it is the easy one: the guide says that to use EFS you need "a Premium V2 Arista VeloCloud license or an add-on license (SDEX-EFS-100M-1M) with all other SD-WAN license editions", and the notice lists part numbers stepped by throughput, from 10 Mbps up to 10 Gbps. Translated: either inspection already comes inside the Premium V2 licence, or you buy it separately and by the megabit, with a different step per throughput tier. That goes into a spreadsheet and gets argued about with your account manager.

The expensive part sits underneath. Policy does not convert: the rules, the objects, the groups, the temporary exceptions that have been alive for three years and the reason they were written in the first place — which is almost never written down — all have to be decided again in a different model. And there are sentences in the vendor's own documentation that deserve more attention than the headline.

• The one that contradicts the brochure, signed by the vendor. Although EFS "can be set up with a few mouse clicks", before switching it on you need "a thorough understanding of the network, traffic flows, and current configurations". That is: few clicks, plenty of homework. We have never read a marketing line that contradicts itself so politely.
• The one about performance. "Traffic inspected by the IDPS with Stateful Firewall may experience a performance impact", described as a balancing act between securing the network and keeping it fast. Anyone who sized the Edge to move traffic rather than to inspect it has a pending conversation about the branch that eats the most bandwidth. We look at that before and after in our own monitoring — Zabbix and SmokePing — because the difference between "it feels the same" and "it feels the same except at 12:30" is invisible from the box itself.
• The one discovered late: logging. Logs either go to the vendor's regionally hosted infrastructure or leave over syslog towards your SIEM — the guide cites PCI DSS and NIST as the reason — and that is where the warning nobody reads sits: "It is important to note that syslog traffic is not encrypted". And the hosted one has its ceiling written down: by default it keeps "15 GB of logs per Enterprise or seven days of logs per Edge, whichever comes first", so the window you get to investigate a noisy branch may be a week or less. There is another warning, more domestic and just as real: logging too much "may cause unnecessary stress on the hard disk, potentially causing hard disk failure".

And there are two more warnings we have not seen quoted anywhere, and they change the planning. The first is a CAUTION in the same guide: "Activating or deactivating EFS may cause a disruption in network traffic". Turning the new filtering on is not transparent, and turning it off to roll back is not either: that alone rules out doing it on the same night as the software upgrade. The second sits in the known limitations and weighs more than it looks, because 5.2 is precisely where the VNF road ends: "In 5.2 release, traffic that hits a 1:1 NAT or Port Forwarding rule is not inspected by the IDPS Engine". If that branch has a published camera, a collection server or any port forward, that traffic comes in without passing through the inspection engine. The guide says it will be addressed in a future release; the detail is that the future release is no longer yours if you stay on 5.2 waiting for February.

What is actually being retired is a coupling

Our reading, said as a reading and not as a fact of the notice: what ends in February 2027 is not a product, it is a coupling. The day branch security became a checkbox inside the product that carries the traffic, its calendar stopped depending on you. Nobody is at fault for that: retiring third-party integrations is a normal catalogue decision and a vendor is entitled to make it. What is odd is that on the customer side it is almost never counted as a risk.

The side effect is more uncomfortable than the date. Your filtering now expires on the calendar of a networking software release, 5.2.x. That pushes you into making two changes in the same window — upgrading transport and swapping the security engine — at the site where nobody is around to pick up the phone and, if it goes sideways, over the very network you just touched. When we wrote that SD-WAN does not go down, it gets reconfigured, this is what we meant: in these architectures the scare almost never comes from a cut cable.

Failure is inevitable, an outage is a design decision. Here there is not even a failure. There is somebody else's catalogue decision, announced nine months ahead, which only turns into your outage if February arrives with nobody having looked at it.

When all-in-one is still the right answer

None of this means separating is always better. In a small site with no servers, no point-of-sale and all the work in the cloud, adding another box means another maintenance contract, another firmware and another excuse for nobody to update it. There, all-in-one wins, and we have recommended it ourselves. We already argued it in when SD-WAN pays off and when it is overkill.

The line we draw is a different one: we separate transport from filtering when the branch has something to lose on its own — payments, warehouse, production machinery, regulated data — when the policy and the log have to be demonstrated to somebody external, or when the firewall is operated by a different team from the one that runs the WAN. If none of those three apply, all-in-one is defensible. If any of them does, "integrated" describes the invoice and the rack space, not the accountability.

What we would do this week, not in February

• The list of sites with an active VNF, pulled from the orchestrator and not from the diagram. Brand, version and who pays for that licence. It takes half an hour and it decides everything else; if the inventory comes from the document instead of the system, you already know how it ends: the spreadsheet lies.
• Export the policy while the console is still alive. Rules, objects, groups, NAT and above all the exceptions. Keep it off the appliance. It costs nothing today and cannot be done the day you power the VNF off.
• Measure which rules are actually used before translating them. Counting hits per rule for two weeks separates live policy from archaeology. There is usually more dead weight than anyone admits in a meeting, and whatever survives is what genuinely needs comparing against what EFS can do.
• Split the two windows. First the software upgrade, with the branch running and filtering as it was; then, on a different day, the security engine swap. And neither of them without a way in that does not depend on what you are touching: a 4G link, a backup line, somebody with a key.
• Decide where the log ends up before turning anything on. If the branch logs fed your SIEM from your own vendor's firewall, they are about to change source and format, and so are the dashboards built on them. And if they leave over syslog, send them inside the tunnel: the guide itself warns that this traffic is not encrypted.

What we are not claiming

We are not saying Enhanced Firewall Services is worse than a third-party firewall: they are different things and for many branches the new one is enough. We give no prices, because a part number is not a price and we do not have the rate card. We do not know how many deployments have the VNF switched on — the vendor does not publish that — so we are not measuring the size of the problem, only pointing out that it exists and whose problem it is. And the dates are those in the notice as published today: end-of-life notices get revised, and this one may move. We are not a party to it either: we do not resell VeloCloud or any of the three firewalls mentioned.

Note on sources

All consulted on 17 September 2026. One: the Arista notice "End of Availability for VeloCloud Security VNF Services" (reference 24027), dated 15 May 2026, source of the three affected vendors, the sentence about 5.2.x, the 28 February 2027 end-of-support date, the recommendation to move to Enhanced Firewall Services and the part numbers stepped from 10 Mbps to 10 Gbps. Two: the VeloCloud SD-WAN 6.4 design guide (Enhanced Firewall Services), source of the literal quotes on the Suricata engine, the Threat Intelligence cloud query every 4 hours, the Premium V2 or add-on licence requirement, the line about a few mouse clicks versus the understanding required beforehand, the performance impact warning, the PCI DSS and NIST mention, the two warnings about unencrypted syslog and excessive logging, the default ceiling on hosted logging (15 GB per enterprise or seven days per Edge), the CAUTION about traffic disruption when activating or deactivating EFS, and the known IDPS limitation with 1:1 NAT and port forwarding on 5.2. Three: the VeloCloud 6.4 administration guide, source of the Edge firewall description ("stateful inspection along with application identification"), the EFS feature list, how a security VNF is brought up on an Edge and how the Fortinet licence follows the core count. The context that the VeloCloud business moved from Broadcom to Arista comes from 2025 industry coverage rather than a primary source; we do not lean on it for any technical claim. What is our opinion, flagged as such in the body: that what is being retired is a coupling rather than a product, the criterion for when to separate transport from filtering, and the recommendation to split the change into two windows.