Trusted hardware by 2030 and a machine on Windows XP: aligning a mandated transition with a line that runs until 2035

In August I wrote about legacy on the factory floor: control PCs on Windows XP and 7 that cannot be updated because a patch tears the vendor warranty or crashes the process. The conclusion was simple: since the host's vulnerability cannot be removed, you remove its reachability and blast radius. Wrap it, do not patch it.

Since then the regulator has joined the picture. Russian government decree 1912 of 14 November 2023 mandates the transition of significant critical infrastructure objects to the predominant use of trusted hardware and software platforms, in local shorthand trusted PAKs. The transition period runs from 1 September 2024 to 1 January 2030. For a plant whose production line sits on foreign controllers, bought in 2019 and rated to run until 2035, that sounds like an order to tear out working equipment to meet a calendar.

It is not, but it cannot be waved away either. This piece is about how two plans, the transition plan under the decree and the life plan of the line, fit together. The reader is the same as in August: an owner or production director with a categorised plant and five people in IT. Readers outside Russia will recognise the shape of the problem from sovereignty and supply-chain rules elsewhere: a mandated technology swap colliding with equipment lifetimes measured in decades.

What the decree actually requires

Start with what it does not require. It does not require replacing everything foreign by 2030. The word "predominant" is deliberate: the sector plan sets target shares of trusted platforms, not a hundred percent swap. It does not require discarding what was bought before 1 September 2024: the ban on buying non-trusted platforms applies only to purchases after that date. And it does not apply to objects that have no significance category.

Now what it does require.

• After 1 September 2024, buy only trusted. Any new controller, server, switch or system for a significant object must be a trusted platform if a trusted equivalent exists.

• Have an operator's transition plan. It follows the sector plan approved by the responsible ministry, and a copy is sent there. From 2026 the operator reports annually by 1 March. Sector plans are marked for official use only, so target shares by sector are not published.

• Deviate only when no trusted equivalent exists. The absence has to be confirmed by a conclusion from the Ministry of Industry and Trade. That is the only legal route for a node that has no replacement.

• Reach the target share by 1 January 2030. According to the digital ministry, by March 2025 more than two thirds of significant objects had moved to domestic software. That means the regulator considers the deadline realistic, which explains the next point.

In April 2026 the digital ministry, on instruction from a deputy prime minister, began drafting amendments to the administrative code: for missing the deadline or breaching the transition procedure, a fine of 300,000 to 700,000 roubles for a company and 100,000 to 200,000 for an official. The draft is still in development, but the direction is clear: 2030 is turning from a target into a deadline with liability.

The wider context is in 187-FZ nine years on: sector-wide object lists closed self-assessment, and a plant that decided in 2017 it was not an operator is now, with high probability, an operator with a significant object.

What a trusted platform is, and why the controller on the line will not become one

Under the decree a platform is trusted if three conditions hold at once: the hardware is listed in the industry ministry's registry of Russian electronics, the software is listed in the digital ministry's registry of Russian software or the Eurasian Union registry, and if the platform performs protection functions it meets the security regulator's requirements.

For servers, switches, workstations and security tools, trusted options exist and their share is growing. In the process loop the picture is different. Specialised controllers, process control application software tied to specific equipment, communication modules speaking a vendor's industrial protocols often have no equivalent at all, and where one exists, replacement means redesigning the control system and stopping the line. Practitioners were writing this in 2022, and four years on it has changed less than anyone hoped.

The market is meanwhile arguing about what trust even means. Some read the decree literally, as the origin of components. Others propose understanding trust as reliability, manageability and control across the whole life cycle. The trusted platform standard is being revised in 2026, and which reading it will settle on is unclear. For a plant this means the definitions may move while the deadline does not.

Two approaches to the transition, and why the second is cheaper

The author of the piece on cyber resilience I discussed in the air gap illusion, contrasted a mechanical box-for-box replacement with what he called "import outpacing": a comprehensive digital transformation project where technology is chosen for transparency and controllability rather than geography. Full domestic transition for mission critical systems, a balance for the rest.

I agree, and will add what it looks like at a mid-sized plant. Box for box means the transition plan lives apart from the line's modernisation plan, and in 2029 the plant stops working equipment to replace it with whatever it managed to find. Import outpacing means the transition plan is tied to scheduled shutdowns, to end-of-life dates and to modernisations the plant was going to do anyway. The same replacement, but at the moment when it costs a third as much, because the line is stopped regardless.

The underlying logic of "own or foreign" I set out in 2017 in import substitution for IT leaders and in 2022 in architectural sovereignty. The thesis stands: controllability matters more than origin, and what you cannot fix yourself is not yours, wherever it was made.

A node map: four classes, four decisions

In the 187-FZ piece I proposed adding three attributes to the inventory: trusted or non-trusted platform, country of origin of the security tool, end-of-support date. Now a fourth joins them: does a trusted equivalent exist. Four attributes give four classes of node, each with its own decision.

Class one: an equivalent exists, service life ends before 2030. The simplest. The replacement goes into the transition plan on the scheduled retirement date, and the budget matches what was already set aside for renewal. The one thing to do in advance is check that the chosen equivalent is actually in the registries, rather than "Russian" by the sign on the door.

Class two: an equivalent exists, service life ends after 2030. This is where the share is decided. The node goes into the plan for the next shutdown or modernisation at which it can be replaced with minimal loss. Until then it runs with compensating controls. If there are many such nodes and the share does not add up by 2030, that is a conversation with the sector ministry at the planning stage, not in 2029.

Class three: no equivalent. A specialised controller, a vendor's application software, a protocol module. For it, a no-equivalent conclusion is obtained from the industry ministry, and the node is wrapped: isolation in its own segment, vendor access control, a diode or firewall with virtual patching, host allowlisting, a recovery image. Everything from the August piece, except that now it is not just protection but a documented justification the operator shows the regulator.

Class four: the object is not significant. Decree 1912 does not apply. But presidential decree 250 on security tools applies to all critical infrastructure operators, and so does the 2025 requirement to prefer Russian software where an equivalent exists. So "not significant" does not mean "do nothing"; it means "act only on security tools and new purchases".

The four-class map is built on the inventory the law already requires. The difference is that each node gets a decision and a date, and the table becomes a plan that can be shown to the ministry and defended before the owner.

Compensating controls as a justification, not an excuse

The most common mistake I see looks like this: the plant writes "replacement impossible, compensating controls applied" in the plan, and nothing more. The regulator reads that as "did nothing and do not intend to". For compensating controls to work as a justification they need three properties.

First, they are described concretely. Not "segmentation" but a diagram of the segment with the rules at its boundary, a list of permitted connections, a vendor access log with retention. Something an inspector can check against reality.

Second, they have an end date. Compensating controls are not a permanent regime but a bridge to the date when the node is replaced or retired. The date is in the plan, tied to an event on the line rather than to the regulator's calendar.

Third, they close the risk, not just the clauses. I have seen plans where the controls were chosen to tick the boxes while the node remained reachable through a commissioning engineer's laptop. Such a justification collapses at the first incident, and under FSB order 547 an incident has to be reported to the national coordination centre within a day. What must be preserved by the time of the investigation is in an accident investigation needs a digital trace.

A separate note on new purchases with AI. A vendor's predictive maintenance model or a cloud set-point optimisation service for a significant object is also a platform or software to which the registries apply, along with clause 60 of FSTEC order 117 on handing protected information to external services, which I covered in section 3.18 of the methodology. A plant that installs a foreign model on a significant object in 2026 creates a class-three node out of thin air.

Money: how to justify the sequence to the owner

Investment budgets are being cut, and the transition plan competes with a roof repair. So the sequence I defend before owners rests on one principle: first what coincides with planned spending, then what closes the most expensive risk, and last the unscheduled replacement of working equipment.

First: class-one nodes. That is money already set aside for renewal, just with the right choice of supplier.

Second: security tools under decree 250. That is already a violation rather than a risk, and it is the cheapest part of the transition, because a firewall costs less than a controller.

Third: compensating controls for class three and the ministry conclusions. That is mostly work rather than purchases: segmentation, logs, documents.

Fourth: class-two nodes tied to shutdowns. Here the budget appears when the shutdown appears, and that is as it should be.

On the risk the owner weighs against this plan, I will be honest. A fine of 700,000 roubles is less than a day of line downtime, and the owner works that out quickly. But the fine is not the main risk. The main risk is that after an incident on an unprotected class-three node, an investigation under article 274.1 of the Criminal Code reaches the people who signed the plan. That is the argument I give second, after the economics, and it usually decides.

Honest caveats

• I have not seen the sector plans. They are restricted, and target shares by sector are absent from open sources. Everything I wrote about shares is the logic of the decree, not your ministry's numbers. Those have to be requested from the ministry directly.

• The practice of ministry conclusions has not settled. Methodological recommendations for the defence, mining, metals and chemicals sectors came out in October 2024, but how long a conclusion takes and how the ministry reads "no equivalent" depends on the sector and keeps changing. Budget months, not weeks.

• The definition of a trusted platform may change. The standard is under revision in 2026. A plan tied to events on the line will survive a change of definition better than a plan tied to the current registry listing.

• I do not sell platforms. My interest here is that the transition is planned, not which vendor executes it. Supplier choice is a separate conversation in which I am on the plant's side.

In short

• Decree 1912 requires predominant, not total, use of trusted platforms on significant objects by 1 January 2030. What was bought before 1 September 2024 need not be discarded; new purchases must be trusted.
• A trusted platform means three registries at once. Equivalents exist for servers and networks; for specialised controllers and process control software they often do not, and the only legal route there is a ministry no-equivalent conclusion.
• Box-for-box replacement on the regulator's calendar is expensive. Tying the plan to scheduled shutdowns, end-of-life dates and modernisations, what that author calls import outpacing, costs a fraction.
• Four node classes from four inventory attributes: equivalent exists and life ends, equivalent exists and life continues, no equivalent, object not significant. Each has its own decision and date.
• Compensating controls work as a justification only if they are concrete, have an end date and close the risk rather than the clauses.
• Spending order: planned replacements, security tools under decree 250, justifications and isolation for the irreplaceable, replacements at shutdowns. The fine is less than downtime, but criminal liability weighs more than the fine.

If you have a significant object, a line on foreign controllers and a transition plan that so far exists as a letter to the ministry, I help turn the inventory into a node map with decisions and dates that can be defended before both the ministry and the owner. Feel free to get in touch; the first conversation commits you to nothing.