Russia's 187-FZ nine years on: what changed since 2017 and what to do in 2026

In July 2017 I wrote about Russia's freshly adopted law on the security of critical information infrastructure: 187-FZ as a separate agenda. Back then it was a frame. No secondary regulations, no deadlines, and most mid-sized companies settled on a comfortable position: "this is about power utilities and banks, not us."

Nine years later that position has become the most expensive one available. The law grew new decrees and orders every year, but the break came in 2025, and many missed it because it did not look like one big event. It was a series of modest documents that together closed the loopholes "not us" had rested on.

This piece is for the owner or operations director of an industrial company who decided in 2017 that the law did not apply and has not revisited the question since. Readers outside Russia can treat it as a case study: a strict critical-infrastructure regime, comparable in intent to NIS2 in the EU, that moved from self-declaration to enforcement in under a decade. I walk through four shifts and rewrite my own 2017 checklist for 2026.

Why "not us" worked for nine years

The 2017 design gave the operator the right to assess for itself whether it had significant objects. A company formed a commission, the commission listed its objects, assigned categories and sent the results to FSTEC, the technical regulator. Or did not send them, having decided there was nothing significant.

That created the self-assessment loophole. A plant with a dispatch system and process control on a production line could honestly conclude its systems fell short of a category, because the impact criteria left room for interpretation. The regulator only saw what it was sent. Administrative liability for violations arrived only in 2021, and inspections reached the large players first.

Under that design, doing nothing was rational for a mid-sized enterprise. In 2017 I advised an inventory and a topology review "just in case". For most, the case never came, and the advice went into a drawer. That is an honest observation, not a reproach.

Shift one: self-assessment closed by sector lists

Amendments to 187-FZ adopted through law 58-FZ of 7 April 2025 took effect on 1 September 2025. The key change for a mid-sized enterprise is a mechanism of typical sector-specific critical infrastructure objects. The government approves, sector by sector, lists of typical objects and sector-specific categorisation rules, and the operator must check its own systems against that list.

The difference is fundamental. Previously the commission decided whether it had an object at all. Now the list states that a process control system at a facility in a given sector, a dispatch platform or a sector-specific accounting system is an object by default. The commission is left to determine the category, and the sector rules narrow its room for interpretation there too. The categorisation rules require previously assigned categories to be reviewed once the lists are out.

A second change in the same package removed individual entrepreneurs from the scope of the law. A small detail, but telling: the legislator was not broadening the circle, it was cleaning it to concentrate enforcement on those with something to protect. If you are a plant, you stayed on the list.

Shift two: hardware and software became regulated

In 2017 the law was silent on what the objects ran on. Today that is one of its main themes.

Government decree 1912 of 14 November 2023 set the transition of significant objects to trusted hardware and software platforms. Since 1 September 2024 the purchase of non-trusted platforms for significant objects is prohibited, sector ministries approve transition plans with target shares, and the plans run out to 2030. The 2025 amendments added an obligation to prefer Russian software whenever the national registry holds an equivalent.

Presidential decree 250 of 1 May 2022 works alongside. Since 1 January 2025 critical infrastructure operators may not use information security tools produced in "unfriendly" states or by organisations they control. That covers firewalls, antivirus, intrusion detection. For many plants it means a perimeter built in 2019 on imported equipment has formally been out of compliance for almost two years.

I wrote about the replacement theme itself back in 2017 in software import substitution in Russia and returned to it in 2022 with architectural sovereignty and open source. What changed since: a recommendation turned into a plan with dates and shares that the ministry hands down to the operator.

Shift three: the regulator stopped reading binders

FSTEC order 117 of 11 April 2025 took effect on 1 March 2026 and replaced order 17, under which state information systems had been protected since 2013. Formally it covers state systems, and a plant is not directly in scope. But it is the clearest signal of where the regulator is heading, and the requirements for significant critical infrastructure objects under order 239 are moving the same way.

The substance of the shift: instead of a finite list of measures and an attestation every few years, a process approach. Protection is described as a set of processes that run continuously, vulnerabilities are fixed within set deadlines, and the level of protection is a metric that must be recalculated. The methodological document issued with the order in April 2026 contains a separate section on protecting information when artificial intelligence is used: an isolated environment for model development, integrity control for training data and the model, logging of prompts and responses.

For an owner this means one practical thing. A binder of policies and an attestation certificate from three years ago stops being an argument. The regulator's question now reads "show me that it works today". I described the same approach from the other side this spring, when I argued that data, IT and security cannot be separated: protection as a property of the system, not a separate folder.

Shift four: incident reporting became a technical duty

In 2017 connecting to the national attack detection system, GosSOPKA, looked like a distant prospect for large operators. Today it is a working duty. A computer incident at a critical infrastructure object must be reported to the national coordination centre, NKTsKI, within 24 hours; for significant objects the interaction has to be continuous and technical, and the FSB updated the procedure for it at the end of 2025.

Liability that did not exist in 2017 comes with it. Article 13.12.1 of the Administrative Code sets fines for violating the requirements and for failing to report an incident, up to 500,000 roubles for a legal entity. Article 274.1 of the Criminal Code covers unlawful impact on critical infrastructure, and its third part applies to a company's own staff for breaching operating rules in a way that caused harm. That is the part a plant's IT director usually learns about last.

What it means for a plant with three hundred people

Let me assemble a typical profile. An enterprise in metals, chemicals, power or mining, three hundred to fifteen hundred people. An ERP, several lines with process control on foreign controllers, an IT department of five, and security handled by a sysadmin on the side. In 2017 such an enterprise decided the law was not about it, and in its own way it was right.

In 2026 the picture looks like this:

• the enterprise has a critical infrastructure object, because its process control or dispatch system is described in the sector list, and the category has to be reviewed;
• if the object is significant, a transition plan to trusted platforms with shares and dates comes attached, handed down by the sector ministry;
• foreign-made security tools on that object have been out of compliance since January 2025;
• an incident must be reported within a day, and for that it first has to be seen.

The good news is that this does not mean "buy everything at once". Investment budgets are being cut across the market, I see it in my own conversations, and the regulator understands it too: that is exactly why the transition plans stretch to 2030. The bad news is that the question can no longer be deferred another year, because the categorisation review and the ban on foreign security tools carry no grace period.

The 2017 checklist, rewritten for 2026

In that piece I proposed five questions. Here is how they sound today.

1. Then: "do we fall under the definition of an operator?" Now: which of our systems appear in the typical sector list, and when did we last review the category. The answer "we categorised in 2019" means the review is due now.

2. Then: "do we have an inventory of production systems?" Now: does every node in the inventory carry three attributes: trusted or non-trusted platform, country of origin of the security tool, end-of-support date. An inventory without those columns is useless for a transition plan.

3. Then: "who is responsible for the security of industrial systems?" Now: who signs the report to the coordination centre at three in the morning, and does that person have the technical means to see the incident rather than hear about it from a line operator.

4. Then: "is the security team familiar with process control specifics?" Now: can the security team show the regulator running processes rather than a binder. A vulnerability log with dates, a list of segments with the rules between them, the last response exercise.

5. Then: "do we have a plan for an incident in production infrastructure?" Now: the plan has been rehearsed at least once, and it accounts for models and agents if they sit in the loop. I wrote about that separately: AI on the factory floor and attacks on the model's judgement. Tampered telemetry that made a model stop a line is, in the eyes of the law, a computer incident too.

Where to start after nine years of doing nothing

The sequence I suggest for the first three months.

First: reconcile with the sector list and review the category honestly. It is paperwork, but it sets the scale of everything else. Understating the category has become risky, overstating it has become expensive.

Second: a map of systems with the three attributes from question two. The map is made on foot, because a plant always has nodes the IT department discovers during a walk-round.

Third: reporting readiness. An agreement on who sees an incident and how, who reports, through which channel. This can be done in a week and closes the duty with the fastest consequences.

Fourth: a transition plan for security tools and platforms, aligned with the budget. Nodes closest to the process and furthest from end of life go first. Old equipment that can be neither updated nor replaced by the deadline is wrapped in compensating controls; I covered that in detail in legacy on the factory floor.

Fifth: segmentation between the corporate and the process network, if it still does not exist. I gave that advice in 2012 after Stuxnet, and it remains the cheapest one that works.

Honest caveats

• The rules change faster than pieces like this come out. Some of the 2026 documents have only just taken effect or still exist as drafts. I give the direction and the logic; specific numbers, dates and wording must be checked against the primary sources on the FSTEC site and the official legal publication portal before any decision. This is not legal advice.

• Your commission signs the categorisation. A consultant can prepare the materials and show how the criteria are read, but the operator carries the responsibility for the category. I do not claim otherwise, and I talk out of it anyone who wants to delegate it.

• The move to trusted platforms will not happen everywhere by the deadline. On a production line that runs on foreign controllers until 2035, replacement is physically impossible. There, compensating controls and a justification for the regulator do the work, and that is a separate conversation I will come back to.

• Compliance and security are still different things. But in 2026 the regulator at least asks whether processes run, not whether paper exists. That brings the two goals closer than at any point since 2017.

In short

• In 2017 the law gave the operator the right to decide for itself whether it had significant objects. "Not us" rested on that right for nine years.
• Since 1 September 2025 typical sector lists of critical infrastructure objects apply, and categories must be reviewed against them rather than at the operator's discretion.
• Hardware and software became regulated: a transition to trusted platforms with dates out to 2030, preference for Russian software, a ban on foreign security tools since January 2025.
• The regulator is moving from binders to processes: FSTEC order 117, in force since March 2026, sets an approach that reaches critical infrastructure too, including requirements for AI in the loop.
• A 24-hour report to the coordination centre plus administrative and criminal liability turned incident reporting from a prospect into a working duty.
• Start with the category review, a system map with platform and security-tool attributes, reporting readiness, and a transition plan aligned with the budget.

If your enterprise decided in 2017 that the critical infrastructure law did not apply, now is a good time to re-check that decision before the regulator does it for you. I help work out which systems are genuinely in scope, which gaps a plan closes and which need compensating controls, and in what order to spend the money. Feel free to get in touch; the first conversation commits you to nothing.