Thought Leadership
A Draft EU Text Drops the Three-Year Huawei Deadline. The Phase-Out Would Follow the Refresh Cycle
EU governments have struck the fixed 36-month Huawei phase-out from their draft of the new Cybersecurity Act. The text is a document dated 22 September 2026 and seen by Reuters, according to 2LT News and EU Today. Citing Reuters, Techzine reported on 30 September 2026 that the member states "removed that specific timeframe from the draft text". The deadline applied to mobile networks. Timing would instead follow risk, product lifecycles, replacement cycles and the availability of alternatives. Nothing is final: governments and the European Parliament still have to agree a text.
In our view, the missing date is not a reprieve. A phase-out with a fixed deadline is a project with an end. A phase-out tied to your refresh cycle never ends, because every lifecycle decision you take on network gear from a listed supplier becomes a compliance decision someone can question later. This post sets out what the draft changes, what it does not touch, and why we think enterprise firewall teams should read it as a template rather than as telecom news.
What exactly did the draft change?
The draft removes one number from the Commission's proposal and replaces it with criteria. The Commission published its recast Cybersecurity Act, COM(2026) 11, on 20 January 2026. Its Article 110(3) caps the phase-out of high-risk suppliers' components from key mobile network assets: the periods "shall not exceed 36 months from the publication of the list of high-risk suppliers". The government draft deletes that cap.
According to EU Today's account of the 22 September draft, published 29 September 2026, the timetable should instead "take account of the level of identified risk, product and infrastructure lifecycles, normal equipment replacement cycles, interoperability requirements and the availability of suitable alternatives." The same report says equipment judged to present an immediate or particularly serious risk could face a shorter deadline.
| Commission proposal (20 January 2026) | Government draft (dated 22 September 2026) | |
|---|---|---|
| Mobile networks | Phase-out within 36 months of the high-risk supplier list | No fixed period |
| What sets the timing | A legal maximum | Risk level, lifecycles, replacement cycles, interoperability, alternatives |
| Serious-risk equipment | Same 36-month cap | Could face a shorter deadline |
| Fixed and satellite networks | Periods to be set later by implementing act | Not reported as changed |
| Status | Proposal | Negotiating text, not law |
The pressure behind the change is public. On 15 September 2026, Euronews reported an open letter from the Connect Europe lobby group, signed by 17 senior telecom executives, warning that the rules risk "draining the sector of the very capital needed for fibre, 5G and 6G". Deutsche Telekom chief executive Timotheus Höttges and 16 other executives put the replacement cost at up to 40 billion euros, per Techzine and 2LT News.
Does the high-risk supplier regime reach enterprise firewalls?
Not by name, and not yet. The proposal's supply-chain chapter is drawn wider than telecom, but it reaches a specific product only once the Commission lists it. Article 98 applies to the entity types in Annexes I and II of the NIS2 Directive, which Hogan Lovells counts as 18 critical sectors. "The mechanism shall identify key ICT assets in critical ICT supply chains," the article says.
Which assets count is left to later decisions. Under Article 102 the Commission identifies key ICT assets by implementing act. Under Article 103(1) it can then bar those entities from using high-risk suppliers' components in those assets, and such acts "shall provide for appropriate transition periods", plus "additional time periods for phasing out the relevant ICT components". No such act exists, because the regulation itself is not adopted. Hogan Lovells expects adoption in the course of 2027 at the earliest. The proposal's text does not mention firewalls, and the only list of key assets so far, Annex II, covers mobile, fixed and satellite electronic communications networks.
So the honest answer for an energy utility, a hospital or a bank is: your firewalls are not in scope today. They could be brought in by one implementing act. And Chinese vendors are in the enterprise firewall market: BankInfoSecurity's report on Gartner's 2025 Hybrid Mesh Firewall quadrant listed Huawei, H3C and Sangfor among the Niche Players.
Our opinion: the telecom text is the template. Article 103(1) already gives the general mechanism "appropriate transition periods" and "additional time periods for phasing out" rather than a number. If the governments' draft survives for mobile networks, a sector that lobbied hard against the cap will have set the norm that phase-outs follow the refresh cycle, and that norm is the likeliest one any later act for NIS2 sectors would copy.
Why is a phase-out without a deadline harder to run?
A phase-out without a deadline is harder to run because the burden moves from finishing a project to justifying every asset, every year. With a fixed date, you plan backwards, fund one programme, and prove compliance once, when the last box leaves. With a lifecycle-tied phase-out, the question an auditor or regulator asks changes from "is it gone?" to "was it replaced when it should have been, and why not earlier?"
That question lands on decisions firewall teams take all the time and rarely write down: extending support by a year, buying a spare chassis of the same model, renewing a threat subscription, approving an expansion module. Under a refresh-cycle rule, each of those is evidence of when you intended to replace the platform. A support extension on listed-supplier gear stops being a budget call. It becomes a statement about your phase-out date.
| Question | Fixed deadline (36 months) | Tied to refresh cycle |
|---|---|---|
| When is the work done? | On a known date | When each asset reaches its own replacement point |
| Planning unit | One programme | Every asset, at every lifecycle decision |
| What you must prove | The equipment is gone | Each replacement date was reasonable, and no extension delayed it |
| Who decides the date | The legislator | You, then whoever reviews your reasoning |
| Typical failure | Missing the date | An undocumented renewal that quietly pushed the date out |
| Change-process impact | One large migration window | Every refresh, extension and renewal ticket needs a lifecycle rationale |
We think most teams are better at the left column. They have run hardware refreshes against an end-of-support date before, as our Cisco ASA end-of-support analysis shows. Very few keep a per-asset record that explains why a given box is still in the rack.
What did Germany do with its own 5G phase-out?
Germany chose dates over cycles. On 11 July 2024 the Federal Ministry of the Interior announced an agreement with the mobile network operators: critical Huawei and ZTE components out of 5G core networks by the end of 2026, and critical functions of their network management systems in the access and transport networks replaced by the end of 2029, as the Associated Press reported the same day.
Two details matter for firewall teams. First, Germany treated the management system as its own phase-out item with its own date, three years after the core. That matches our argument in the hybrid mesh firewall post: the console is where lock-in lives. Second, a fixed national date and a flexible EU timetable can coexist. A German operator would still be held to its 2026 and 2029 contract dates whatever Brussels settles on.
What lifecycle evidence should you hold per asset?
Hold enough per asset to show, at any point, why it is still in service and when it will leave. For firewalls and other network security gear from any supplier that could plausibly be listed, we would keep six fields in the asset register, each with its source:
- Supplier and control: the manufacturer, the management software vendor, and where support is delivered from. As Gleiss Lutz summarises the proposal, a supplier counts as high-risk when it is located in or controlled from a designated third country, so the brand on the faceplate is not enough.
- Published end-of-sale and end-of-support dates for hardware, operating system and management platform, each separately.
- Planned replacement date and the document that set it: a refresh plan, a budget line, a board decision.
- Every extension since that plan, with the reason and the approver. This is the field a refresh-cycle rule will test hardest.
- Alternatives assessed: which replacement platforms were evaluated and why the move has not happened. "Availability of suitable alternatives" is one of the draft's own criteria.
- Interoperability dependencies: what breaks if the box goes, such as VPN peers, dynamic objects fed by other systems, and integrations into the management plane.
None of this is new work in principle. Our NIS2 firewall evidence guide covers the change records auditors already ask for, and our piece on firewall changes as legal evidence covers how long those records have to hold up. The difference is that lifecycle fields now sit inside the change record, so a renewal ticket without a lifecycle rationale is incomplete.
How is this different from a sudden vendor ban?
It is the opposite failure mode. In our post on firewall vendor geopolitical risk we looked at a regulator that can move from announcement to verdict in about seven weeks, with an end-of-support table to show how short that notice is. That is a clock you cannot meet. The EU draft offers the reverse: almost no clock, and a duty to explain your own.
Both end in the same place, a migration, and both are decided by people outside your network team. Across hundreds of migrations, the hard part was rarely the rule conversion. It was the object model, the integrations and the history of why each rule existed, the classes we list in our migration failure taxonomy. A slow, lifecycle-paced phase-out gives you time to do that work properly. It also makes it easy to put off indefinitely, which a refresh-cycle rule will eventually expose. Estates running two vendors on purpose, as in our multi-vendor management guide, have the easiest path: they can move capacity without a single cut-over.
What happens next?
Three things will decide whether this reaches your firewalls. The first is the final text: governments and the European Parliament still have to agree, and the Parliament could restore a fixed period. The second is the high-risk supplier list under Article 104, which starts any clock that remains. The third is the implementing acts under Article 102 that would name key ICT assets in NIS2 sectors beyond telecom, and under Article 103 that would restrict suppliers for them. Fixed and satellite networks are already in Annex II, but, as Cullen International noted, "no specific phase-out timing has been set for these networks yet."
Until then, in our view, the cheapest preparation is the evidence above. It costs little to record a replacement date and its reason when you take the decision. Reconstructing three years of renewals for a regulator is expensive.
Could you show today, per firewall, when it will be replaced and why it has not been already? The free NIS2 Readiness Check walks through the change and lifecycle evidence a firewall estate has to produce.
