Never Put a Management Interface on the Internet. Here’s the Design I’d Use Instead.

French supermarket fridges, an Ivanti zero-day and a Cisco gateway flaw all landed in one week. A practical blueprint for management VRFs, jump hosts, VPN with MFA, allow-lists and off-box logging.

Image: AI-generated illustration.

Earlier this month hackers pushed the fridges in hundreds of French supermarkets up to 50C, through controllers anyone could reach from the internet. France’s national CERT followed with an alert, and buried in its summary is the most boring sentence in security, and the most ignored one:

“De manière générale l’exposition d’une interface de gestion sur Internet est contraire aux bonnes pratiques.” (Translated: “Generally speaking, exposing a management interface on the Internet is contrary to good practice.”)

That’s from CERT-FR alert CERTFR-2026-ALE-012, first issued Oct 12. Les Mousquetaires first said about 150 of its stores were hit, with fridges heated up to 50C for about six hours, per The Guardian. It later doubled that to 300 Intermarché and Netto stores, BFMTV reported.

That same week, CISA warned that a zero-day authentication bypass in Ivanti Connect Secure, CVE-2026–104935, was being exploited for credential theft and data exfiltration. A day later Cisco disclosed CVE-2026–76519 in Secure Email Gateway, exploited in the wild, with root command execution on the box.

Three different products. One shared trait: they sit at the edge, reachable by anyone. I won’t rehash the advisories. I want to talk about the design that makes this kind of week less scary.

The rule I start every review with

Every device has two jobs. It does its actual work, like routing, cooling food, or filtering mail. And it gets managed. Those two jobs deserve two separate networks.

My rule of thumb: if you can reach a device’s management login page from a coffee shop, the design is already wrong, no matter how strong the password is. Patching matters. But a management plane nobody outside can reach doesn’t need to win the patch race on day one. CISA’s edge-device guidance says the same thing: “Remove any internet-exposed management interfaces or use zero trust capabilities that implement a policy enforcement point separate from the interface itself.”

The reference design

Here’s the shape I keep coming back to. It isn’t fancy.

   INTERNET
      |
 [ Edge firewall ] ---- only VPN (MFA) allowed in
      |
 [ VPN gateway ]  (patched first, logged off-box)
      |
 [ Jump host zone ]  MFA again, session recording
      |   allow-list: jump hosts -> mgmt only
 =====|=================================
 |  MANAGEMENT VRF / VLAN              |
 |  switches, firewalls, controllers,  |
 |  BMC/iLO, appliance admin UIs       |
 =======================================
      |
 [ Log collector ] <-- syslog/flow from everything,
                       stored outside the managed devices

 Production / user networks: NO route to the mgmt VRF

Management VRF or VLAN

Put every admin interface in its own routing domain. On switches and routers that means a dedicated management VRF, so the management plane doesn’t share a routing table with user traffic. For appliances that only have one interface, a dedicated VLAN behind a firewall does the same job.

The test I use is simple. From a normal user subnet, can you ping, or even get a TCP handshake from, a switch’s management address? If yes, you have a flat management network wearing a VLAN tag as a costume.

Jump hosts, not direct access

Admins don’t connect to devices. They connect to a jump host, and the jump host connects to devices. That gives you one place to enforce MFA, one place to record sessions, and one place to cut off when somebody leaves.

Treat the jump host as the most sensitive server you own, because it is. No email, no browsing, no shared local accounts.

VPN plus MFA, and keep the VPN honest

CERT-FR’s own fix is to restore access “uniquement via un VPN sécurisé ou un réseau protégé” (translated: “only via a secure VPN or a protected network”). Agreed. But look at this week again: the Ivanti box is a VPN gateway. The VPN is the one thing you’re deliberately exposing, so it has to be the most patched, most watched device in the building.

Get Mehboob Merchant’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

That’s why I don’t let the VPN land users straight in the management VRF. VPN gets you to the jump zone. Phishing-resistant MFA gets you onto the jump host. Two doors, not one.

Source allow-lists

On every management interface, allow admin protocols (SSH, HTTPS, the vendor console) only from the jump hosts. Not “the corporate range”. The jump hosts. The only other sources are the named management services the device actually needs, such as AAA, monitoring, NTP and config backup, each by IP and port. ACLs on the device, plus a rule on the firewall in front of it. Belt and suspenders.

Off-box logging

Here’s a line from Cisco’s advisory that every architect should read twice. It warns that attackers with root “may remove or hide evidence of exploitation,” and recommends checking “the network logs and the firewall logs outside of the impacted device.” CISA’s Ivanti alert makes a similar point: Ivanti’s Integrity Checker Tool may not catch this exploit because the commands run in memory.

So logs that live only on the box are the attacker’s logs. Send syslog and flow data to a collector the managed devices can’t write over.

How “temporary” vendor holes become permanent

This is the part that rarely makes the diagram. A vendor needs remote access to support a chiller, a building system, a storage array. Someone opens a port, “just until the project’s done.” The project ends. The rule doesn’t.

CERT-FR even names the halfway house. In an emergency, it says, filtering source IPs of the refrigeration contractors on a firewall is possible, “mais cette solution ne doit pas être considérée comme pérenne” (translated: “but this solution must not be considered a long-term one”).

In networks I’ve reviewed, the pattern is that vendor rules have no owner and no expiry date. My fix is boring on purpose. Every vendor rule gets a named internal owner and an expiry in the change ticket, and vendors come in through the same jump host as everyone else. If the vendor’s contract says they need a direct path, renegotiate the contract, not the firewall.

A checklist for this quarter

• Scan your public IP space for admin UIs, SSH, and appliance consoles. Assume someone else already has.
• Move every management interface into a management VRF or VLAN with no route from user networks.
• Force admin access through a jump host with MFA and session recording.
• Allow-list jump hosts on device ACLs and on the firewall.
• Treat your VPN gateway as your most exposed asset. Patch it first.
• Ship logs off-box to a collector the devices can’t overwrite.
• Give every vendor rule an owner and an expiry date.

None of this is new. That’s rather the point. The fridges didn’t need a new kind of defense, just an old one applied.

So, honest question: if you scanned your own public addresses this afternoon, how many login pages would you find that nobody remembers opening?

Mehboob Merchant is a security architect (CISSP, CCIE, CISM, CDPSE) with 25+ years in network and security, and founder of Vaultryx AI, which works on AI and LLM security. Follow for practical security architecture writing.