From End of Support to SASE: The 30-Day Firewall Replacement Plan

A thirty-day firewall replacement is achievable only by scoping to risk reduction: identity integration, outbound brokering for private applications, and baseline DNS and web filtering, with branch hardware and full TLS inspection deferred. A like-for-like hardware refresh does not fit, because appliance procurement alone runs four to eight weeks before engineering starts.

You did not choose this project. A date did.

Something on your perimeter has an end-of-support date inside the next few weeks, a like-for-like replacement is not obviously the right answer, and you need a sequence that gets the organisation to a defensible position on time. That is a different problem from evaluating a platform, and it is a different problem from a full rollout. This page owns the first one: the 30-day proof of concept owns evaluation when you have the luxury of choosing, and the 90-day implementation timeline owns the complete multi-site rollout. Both mention thirty days. Only this one assumes the date is not negotiable.

The whole plan is on the page. No form, no gated download — though in fairness, that is less of a differentiator than we expected. We checked page one for firewall replacement plan, replace end of life firewall, sase migration 30 days and emergency firewall migration, and gating is low: under 5% on the end-of-life query, 10 to 15% on the replacement-plan query, and none at all on the emergency query, where page one is entirely community forum threads.

The real gap is elsewhere, and there are two of them. First, every ranking checklist lists milestones — review the rules, stage the hardware, cut over, watch the logs — without a single quantitative exit criterion. None of them say what help-desk volume means the cutover is failing, what authentication failure rate triggers an abort, or how you decide an application is safe to move when the documentation is missing.

Second, every one of them assumes the plan succeeds. Not one provides a defensible fallback for the case where thirty days is not enough, which — if you have an OT site or an undocumented application estate — is a realistic outcome rather than a pessimistic one.

So this plan is built around gates rather than tasks, and it ends with the failure case rather than ignoring it.

The honest precondition for a 30-day firewall replacement

Before anything else: a like-for-like hardware refresh is not available to you inside thirty days. Enterprise security appliance supply chains run at four to eight weeks for procurement and staging, and conventional single-site firewall replacements average five to seven weeks of engineering plus two to four weeks of compliance evidence work. If the replacement units are not already in the building, the hardware route does not fit the window. That is the constraint that makes this plan necessary, not a preference for one architecture over another.

Second precondition, and it is the one that sinks most compressed projects: your identity directory has to be in reasonable health. A Zero Trust platform evaluates access against identity, group membership and device posture rather than IP addresses. If Active Directory or Entra ID carries orphaned administrative accounts, unmapped nested groups, service accounts nobody owns or incomplete MFA enrolment, the policy engine cannot evaluate least privilege and you will produce authentication loops or lockouts.

Independent field data puts identity and policy design at two to four weeks. The emergency track compresses it to seven days and no further. If your directory needs a month of cleanup, the thirty-day plan does not start until that is done, and pretending otherwise is how these projects fail in week three.

Here is the tension stated plainly rather than smoothed over, because you will need it in front of a steering group.

Every emergency-track figure is shorter than the independent field data. That is what “emergency” means, and it is bought with scope control, not with optimism. Full enterprise SASE programmes average six to twelve months; accelerated mid-market projects run 60 to 90 days from scoping to decommissioning. Thirty days is the compressed track, achieved by deferring everything that is not risk reduction.

The five phases and their gates

Five phases across thirty days: discovery and scoping to day 5, baseline configuration to day 12, a 10 to 15 percent pilot to day 19, phased cutover to day 26, and hypercare with decommissioning to day 30. The gate criteria column is the plan — without it this is a checklist, and a checklist cannot tell you whether to proceed.

Three gate thresholds are deliberately left as “the agreed threshold” rather than printed as numbers, because they have to be set against your measured baseline in phase 1 and agreed with the business before the pilot starts. A latency ceiling means nothing without the legacy baseline to compare it to. Set them in writing at Gate 0, and do not adjust them later to let a phase pass.

The rollback triggers

These are not negotiable and they are not judgement calls. The migration lead halts the cutover and executes the 15-minute rollback if any of the following occurs within the first 120 minutes of go-live:

• Packet loss above 3% or unresolvable latency degradation on core ERP, clinical or financial transaction systems.
• Identity provider token validation failures above 2% across the cutover cohort, whether caused by directory sync lag or SAML timeouts.
• Service desk incident volume above 15% of the migrating user population within two hours of go-live.
• Severe real-time media degradation on corporate voice or video — jitter and packet drop beyond tolerance — caused by broken SIP handling or dropped UDP state.

Write these into the runbook before the window opens, with a named person authorised to call it. The rollback is a success condition of the plan, not a failure of it.

What you switch on in week one, and what waits

Week one removes inbound perimeter exposure. Week two adds cloud DNS and web filtering. Week three moves remote workers to brokered access. Week four applies baseline identity controls. Branch hardware, full TLS inspection and porting the legacy rule set are all deferred. Compression works by triage, not by working faster.

That last row deserves emphasis because it is counter-intuitive under time pressure. The instinct is to run the migration tool and inherit the rule base, since that feels like the fast path. It is not. Conversion tools provide syntax translation, not architectural translation, and they fail specifically on complex source NAT, address object hierarchies and rule evaluation order — the parts that produce silent application failures nobody finds until Monday. Publish the applications you can verify, deny the rest by default, and add exceptions as they surface during hypercare.

Existing site-to-site IPsec tunnels can stay up throughout. Replacing branch-to-branch tunnels inside thirty days is unnecessary risk; phase them out during normal maintenance once remote access and egress are stable.

When thirty days is not enough

Five conditions make a safe cutover inside the window unachievable: operational technology sites, monolithic legacy client-server applications, identity infrastructure debt, mandatory change freezes, and contractual notice on the incumbent. Each has a documented interim compensating control. Forcing the date past one of these is how an end-of-support problem becomes an outage.

Operational technology. Industrial networks running SCADA, PLCs or safety instrumented systems under ISA/IEC 62443 or the Purdue model cannot absorb cloud WAN latency variation, and legacy HMIs cannot take software agents.
Interim measure: isolate the obsolete equipment behind an industrial DMZ. External networks never initiate inbound connections into the OT zone. Communications initiate outbound from OT to IT over standardised secured protocols such as OPC UA over TLS, and process historians replicate outbound through unidirectional proxies so there is no IT-to-OT path.

Monolithic legacy client-server applications. Systems with hardcoded IPs, client-side IP binding, non-routable protocols, dynamic RPC negotiation or server-initiated back-channels — older terminal emulators, specialised manufacturing execution systems — break across a brokered architecture.
Interim measure: deploy a software connector inside the application’s own network segment so users reach only that service rather than establishing a full layer-3 tunnel into the corporate network. Where the front end is a web interface on an unpatched OS, put a browser isolation layer in front of it: the client-side exploit path closes without touching the application code.

Identity infrastructure debt. On-premises directories at legacy functional levels, unpatched domain controllers, unmapped nested groups, no federation, no MFA.
Interim measure: this one cannot be compensated for, only sequenced. Fix the directory first and move the deadline, because a Zero Trust policy engine evaluating a broken directory produces lockouts, not security.

Change freezes. Financial reporting cycles, retail peak windows and statutory audit periods legally forbid core infrastructure changes.
Interim measure: execute the week-one hardening — which is configuration on an existing device, not a change of architecture — and schedule the cutover for the first window after the freeze, with the exception documented in the risk register.

Contractual notice and carrier lock-in. Incumbent telecom or managed security contracts with 60 to 90-day cancellation notice, or externally managed BGP allocations needing carrier coordination to re-route.
Interim measure: serve notice immediately, then run the new path in parallel. You will pay twice for a period; that is cheaper than either breaching notice or missing the security date.

In all five cases the mandatory baseline is the same, and it is what an assessor will actually ask about: modify the edge ACLs to drop all inbound internet traffic on external interfaces, unbind the management GUI and SSH endpoints from the internet, restrict all management to an isolated internal VLAN reached through a hardened jump host with MFA, and record the exception formally in the enterprise risk register with a dated remediation plan. Unsupported hardware stripped of external visibility and documented as such is a defensible position. Unsupported hardware with a public management interface is not, under any framework.

What it costs, against the renewal it replaces

A one-year emergency OEM support extension runs €11,000 to €31,000 all-in and returns the identical decision twelve months later. The accelerated migration runs €40,000 to €91,000 in year one and retires the appliance footprint permanently. Both figures assume a European mid-market organisation of 150 to 500 users across two to five sites.

Two honest caveats on that table. Emergency out-of-warranty support pricing varies enormously by vendor — reported surcharges run from standard list renewal up to 200% — so get your own quote rather than using the range. And the migration column consolidates spend that currently sits in separate lines for VPN, web filtering and branch security, so compare it against your total rather than against the firewall renewal alone. The costs that appear after the project rather than during it are in the hidden costs of a SASE migration.

Ring-fence this staffing or the timeline does not hold: a lead infrastructure architect for about 80 hours across the four weeks, an identity and access engineer for about 40 hours in weeks one and two, a service desk lead for about 30 hours from week three, and 40 to 60 hours of external specialist help. Senior infrastructure engineering rates across the Benelux and DACH markets run €120 to €200 per hour, which puts an 80 to 120-hour professional services engagement at €10,000 to €24,000.

What you have to document for NIS2 and a CyFun assessment

The compressed timeline is where change control gets skipped, and change control is exactly what an assessor examines afterwards. Produce these as you go; reconstructing them later is far more work and reads as reconstruction.

Asset management (CyFun ID.AM): an updated asset register showing the firewall hardware lifecycle, firmware versions and a formal decommissioning log.

Access control and configuration integrity (CyFun PR.AC and PR.IP): approved change advisory board minutes including the testing record, a policy mapping delta showing the move from permissive firewall rules to least-privilege access policy, and verified configuration baselines.

Media sanitisation: certificates confirming cryptographic erasure of device storage to NIST SP 800-88 Rev 1 before disposal or archival.

Change governance (DORA Article 9(4)(e) and Commission Delegated Regulation (EU) 2024/1774): if you are a financial entity, every ICT change needs a documented procedure, a formal operational risk assessment, testing in a representative environment and a verified rollback procedure. Article 8 separately requires you to monitor third-party component end-of-support dates — which is the obligation that created this project. The wider picture is in end-of-life systems under NIS2, and if you are still building the estate picture, the dated cross-vendor reference is the firewall and VPN end-of-life tracker — start there before you start here.

Regulatory context worth knowing: CISA Binding Operational Directive 26-02, issued 5 February 2026, requires US federal agencies to inventory end-of-support edge devices within 90 days and complete decommissioning within 12 months. It does not bind you. It does establish a published benchmark for what “reasonable” looks like, and benchmarks of that kind tend to reappear in private-sector liability arguments.

The failure modes that catch compressed firewall migrations

Four recur, and none are exotic: DNS caching and asymmetric routing where TTLs were not lowered in advance, voice breaking on SIP handling, automated rule conversion failing on roughly 10% of configurations, and replacing one end-of-life edge appliance with another carrying the same unauthenticated public listener. All four come from practitioner reports.

DNS caching and asymmetric routing. Cut over without lowering DNS TTLs at least 24 hours beforehand and workstations keep resolving to the decommissioned edge IP, flooding the help desk with timeouts. Failing to verify upstream ARP cache clearing or BGP propagation produces asymmetric loops where outbound traffic takes the new path and return traffic hits the old perimeter.

Voice. SIP and RTP are usually the first services to break. Rushed configurations mishandle SIP application layer gateway settings or fail to hold state for bidirectional UDP media, producing one-way audio and dropped registrations. Exclude real-time media from TLS inspection, route SIP through dedicated egress rules, and test a call before the wave rather than after.

Rule conversion. Covered above, and worth repeating because the pressure to use the tool peaks precisely when you should not: roughly 10% of translated configurations fail, concentrated in complex NAT, routing and access rules.

Replacing one edge device with another. A rushed team swaps an end-of-life appliance for a new appliance and inherits the same problem class — an unauthenticated listener on a public address, and an urgent patch cycle the first time that vendor has a critical edge vulnerability. Initial access via edge device vulnerabilities accounted for around a third of investigated breaches, with four of the five most exploited vulnerabilities sitting on perimeter firewalls, load balancers and VPN gateways, and close to one in three known exploited vulnerabilities on edge devices remaining unremediated across mid-market perimeters.

Moving to outbound-brokered access removes the listener rather than replacing it, which is the single structural difference between the two routes. The step-by-step version of that specific move is in the VPN to ZTNA migration plan, and where projects tend to stall is documented in where mid-market SASE migrations actually stall.

Steelman: renew the support contract and do this properly

A risk-averse IT director can argue that thirty days is reckless and an emergency OEM renewal is the responsible choice. The argument is strong enough that it deserves answering rather than dismissing.

Operational stability. The network exists to keep the business running, not to demonstrate architectural agility. Compressing discovery, staging, piloting and cutover into a sprint means discovery misses things — undocumented dependencies, custom dynamic RPC ports, server-initiated transactions. If a rushed cutover stops ERP, halts a production line or blocks order processing for 48 hours, the direct loss instantly exceeds the cost of a support contract. Paying an OEM €15,000 to extend coverage for twelve months buys the room to map the estate properly and migrate in an orderly way.

Audit exposure. Running unsupported hardware is a hygiene failure under NIS2. But executing a rushed, poorly documented migration creates its own exposure, particularly under DORA, where supervisors examine whether changes were governed by documented risk assessments, validated staging tests and proven rollback. Emergency sprints are exactly where change control rigour gets abbreviated. A supported, stable, fully documented baseline plus a structured six-month roadmap can be the more defensible position in an examination than a completed migration with gaps in its evidence pack.

Engineering exhaustion and technical debt. A stretched team executing a perimeter cutover in thirty days runs on overtime, and under that pressure people make compromises: temporary permissive rules, skipped certificate validation, undocumented routing bypasses, all to hit the window. You end with an unstable deployment, configuration debt and staff who were never trained on the platform they now have to support — which puts the service desk into a reactive posture for months.

Where the argument holds, and where it does not. All three points are correct about a badly executed thirty-day migration, and that is a real risk rather than a rhetorical one. The plan above answers them specifically: gates with written criteria rather than milestones, a proven 15-minute rollback with named abort triggers, a formal CAB record, and an evidence pack produced during the work rather than after it. If you cannot staff that properly, the steelman wins and you should renew.

Two things the argument does not resolve. The renewal is not a decision, it is a deferral — twelve months later the identical choice returns, against hardware that is twelve months further from support and, if it is running a public listener, twelve months deeper into the exposure statistics above.

And the renewal has to actually be available: on several vendors the last date to purchase a support contract falls a full year before end of support, so by the time the end-of-support date is the thing prompting the project, the extension may no longer be purchasable at any price. Check that before you plan around it. Where it is available, well-staffed and properly documented, it is a legitimate choice — and this plan is still what you execute at the end of the twelve months.

If the date is already close

Do the week-one hardening today regardless of which route you take. Unbind the management interface from the internet, drop inbound traffic on external interfaces, and move administration to an internal VLAN behind a jump host with MFA. That is configuration on hardware you already own, it takes an afternoon, and it removes the exposure that both the exploitation data and a CyFun assessment are actually about.

Then decide the route with the numbers rather than the calendar. If you want help doing that against your own estate, two ways in:

Send us your device list and your date. We will map what has to move before the deadline, what can defer safely with the interim controls above, and what the phases look like against your identity setup — written up as a plan you own, whether or not you buy anything. Get in touch.

Or see the platform against your own applications first. A working session on your top ten applications and your directory, so Gate 0 and Gate 1 stop being hypothetical. Book a demo.

Jimber is an EU-sovereign SASE and Zero Trust platform, and the single property that matters to this particular plan is that remote access, web egress and private application access sit on one platform rather than three — which removes integration work from the phase sequence when the window is this tight. The plan itself is not vendor-specific and is executable with any comparable platform; a plan that only works with one vendor is a quote, not a plan. Platform detail is at jimber.io/sase and jimber.io/ztna-network-isolation, and if the driver is Fortinet-specific, the FortiOS 7.2 end-of-support position and the FortiGate hardware timeline give you the dates.

Frequently asked questions

Can you really replace an enterprise firewall in 30 days?

Yes, but only by defining scope strictly around risk reduction. The window covers identity integration, outbound brokering for private applications, and baseline DNS and web filtering. It defers branch SD-WAN hardware, full deep packet inspection and granular data loss prevention. A like-for-like hardware refresh does not fit, because appliance procurement and staging average four to eight weeks before engineering starts.

What is a rollback trigger?

An objective threshold that mandates halting a cutover and reverting within a target window, typically 15 minutes. Standard triggers are packet loss above 3% on core business systems, authentication failures above 2% across the cutover cohort, or service desk volume above 15% of the migrating population within two hours of go-live. They are set before the window opens, not judged during it.

What happens if we miss the deadline?

Implement documented interim compensating controls: unbind internet-facing management interfaces, drop all inbound traffic on external interfaces, restrict administration to an isolated internal VLAN through a hardened jump host with MFA, broker remote access outbound rather than terminating it on the appliance, and record the exception in the risk register with a dated remediation plan.

Should we use the automated rule conversion tool?

No, not for this. Conversion utilities provide syntax translation rather than architectural translation and fail on roughly 10% of configurations, concentrated in complex NAT logic, dynamic routing and VPN interfaces. Importing thousands of legacy layer 3 and 4 rules replicates years of technical debt. Publish verified applications, deny everything else by default, and add exceptions during hypercare.

Why is identity cleanup the hardest part?

Because access is evaluated against identity, group membership and device posture rather than IP addresses. Stale accounts, disorganised security groups and incomplete MFA enrolment prevent the policy engine from evaluating least privilege accurately. Cleaning a directory under deadline pressure is also risky in itself, because every change touches live user credentials.

Can site-to-site VPN tunnels stay up during the migration?

Yes, and they should. Replacing branch-to-branch tunnels inside thirty days adds risk without reducing exposure, because that traffic already runs over private transit. Keep the existing IPsec tunnels, move remote users and web egress first, then phase out the site-to-site layer during ordinary maintenance once the new architecture is stable.

Will branch users see more latency?

Branch-to-cloud-to-internet traffic is usually equal to or better than backhauling through a central datacentre firewall. Purely internal east-west traffic between local VLANs should not be routed through a cloud broker at all — local switches keep handling that at line speed, while the cloud fabric governs north-south egress and remote or cross-site private application access.

How do we protect voice during the cutover?

Exclude real-time media from TLS inspection, route SIP through dedicated egress rules, and split-tunnel voice where appropriate. Rushed configurations frequently mishandle SIP application layer gateway settings or fail to maintain state for bidirectional UDP media, which produces one-way audio and dropped registrations. Test a live call before each wave rather than after it.

What evidence will an assessor ask for afterwards?

The initial risk evaluation justifying retirement of the end-of-life equipment, approved change advisory board minutes including the testing record, a written and tested rollback runbook, validation logs demonstrating policy parity, and a sanitisation certificate confirming the old appliance configuration was securely erased. Produce these during the project; reconstruction afterwards is visible as reconstruction.

Is extending vendor support a reasonable alternative?

Sometimes, but check two things first. Many vendors set the last date a support contract can be purchased a full year before end of support, so the extension may not be available. And an extension defers rather than decides: the same choice returns in twelve months against hardware twelve months further from support. Where it is available and properly used to fund an orderly migration, it is legitimate.