When an OT security standard lands on a plant: five reactions, and how a site lead moves the team

The email from group engineering arrives late on a Thursday. A new OT security standard for every manufacturing site, aligned with ISA/IEC 62443, with a gap assessment due back before the end of the year. The site’s automation lead forwards it to the team with one line: “Let’s talk on Monday.”

By Monday the team has already talked: in the control room on the night shift, at the coffee machine next to the packaging hall, in the car park. The meeting itself is short, because everyone turns up with their sentence ready. The senior process engineer: “This was written for refineries. We are a validated pharma site, nothing gets onto that network without change control.” The young controls engineer: “Can we just have the list of things to tick?” The maintenance supervisor: “Fine, but half of it won’t apply to us.” And from the back of the room, quietly: “We have three people and a line that runs twenty hours a day. There is no way.”

None of them is wrong about the facts. All of them are reacting, and whether the standard ever changes anything on that site depends less on the document than on the next six months of conversations.

A borrowed analogy

In the May/June 2020 issue of ISA’s InTech magazine, Eric Cosman, a founding member and co-chair of the ISA99 committee that writes the 62443 series, offered a comparison anyone who has rolled out a security programme in a plant will recognise. He mapped the way asset owners respond to common, cross-industry security standards onto the stages of grief described by Elisabeth Kübler-Ross in her 1969 book On Death and Dying: denial, anger, bargaining, depression, acceptance, each with the sentence asset owners actually say. The table below renames two of them for the words heard on a plant: anger becomes frustration, depression becomes paralysis.

Cosman presented it as an analogy rather than a perfect fit, and it is best read that way. Nobody on a filling line is grieving. The sequence is useful for one practical reason, though: each stage calls for a different answer from whoever leads the change, and the usual mistake is to give one stage’s answer to a team that is in another. Nor are the stages tidy. The technicians can be in frustration while the validation lead is still bargaining. Use it as a map of what you are hearing, not as a timetable.

Why a standard hurts more on a plant than in an office

An IT department that receives a new security framework mostly receives more work. A production site receives something closer to a threat to the way it keeps running.

Start with the validated state. Every change to a GMP computerised system goes through change control, impact assessment and often requalification. A requirement such as “apply security patches” reads, to a validation engineer, as a steady stream of changes to a system that was qualified precisely so that it would stay the same. Then there are assets that outlive their software. The packaging line may be fifteen years old, its HMI on an unsupported operating system, its integrator long gone. Requirements written for new designs land on a system that cannot be redesigned.

• A different vocabulary. The standard talks of zones, conduits, foundational requirements and target security levels. The team talks of lines, units, recipes, batches and campaigns. Until someone translates, the document reads as if outsiders wrote it for outsiders.
• The same people, already busy. Most sites have no separate security team, and on a sterile site the engineers who would implement the programme are still absorbing the revised EU GMP Annex 1, in operation since 25 August 2023, with a contamination control strategy to keep up to date and defend.

None of this makes the standard less necessary. It explains why the first reaction is resistance, and why that resistance usually shows that people have understood what the document will cost them.

Five reactions, and what each one needs

### “We are different”

On a plant, denial nearly always comes as a statement about architecture: we are air-gapped, we sit behind the corporate firewall, nobody targets a mid-sized formulation site. Arguing with it in the meeting gets you nowhere. The sentence is said in good faith, by the people who designed or inherited the network diagram on the wall.

What works is to replace the belief with the site’s own facts, gathered by the team itself. Walk one line with the people who maintain it and list everything that crosses the boundary: the vendor’s remote support modem, the historian interface to the business network, the laptop the integrator brings for every change, the USB stick used to load recipes. The list is usually longer than anyone expected, and nobody had to be told they were wrong. Cosman’s argument helps here too. The threat and the vulnerabilities are largely the same across industries, because everyone buys from the same handful of suppliers and runs the same commercial operating systems and network components. A pharmaceutical line is different in its consequences, not in its Windows.

### “Just give me a checklist”

This is frustration, and it is mostly about language. Standards are written in a precise, formal structure so that conformance can be assessed; to an engineer outside the field, that precision reads as fog. So give them a checklist, just not the one they asked for. IEC 62443-3-3:2013 does contain lists: system requirements grouped under seven foundational requirements, from identification and authentication control to resource availability, each graded by security level. Handed over raw, they become a box-ticking exercise across the whole site that proves nothing. The useful version is short, attached to one zone the team knows well, and written in its own words: who can log on to this HMI, how the vendor gets in, what happens to a recipe file between the office and the controller.

### “It has to be tailored for us”

Well-run sites get stuck longest at bargaining, because it sounds like professionalism, and partly it is. The series expects tailoring. IEC 62443-3-2:2020 does not say “do everything”. It asks you to identify the system under consideration, run an initial risk assessment, partition it into zones and conduits, assess the risk of each, set a target security level for each, write a cybersecurity requirements specification and have the asset owner approve it. IEC 62443-3-3 itself allows compensating countermeasures where a requirement cannot be met without breaking a fundamental operational need. The NIST Cybersecurity Framework 2.0 works the same way with its Current and Target Profiles. Tailoring is built into the method.

The trap is tailoring that never ends: the gap analysis on its fourth revision, every requirement marked “N/A because the system is validated”, a monthly meeting on the scope of the scope. At that point the lead has to turn bargaining into decisions. Each exception gets a written rationale, a compensating measure, an owner and a review date. Whatever is left is a requirement, and it goes on the plan.

### “We will never get there”

Paralysis usually follows the first honest gap assessment: the whole site against the whole standard, several hundred gaps, a budget nobody has and a headcount that has not moved. IEC 62443-2-1, the part that sets out the security programme requirements for asset owners (its second edition came out in August 2024), read end to end by a site with three automation engineers, is a reliable way to lose heart.

The answer is to shrink the horizon until progress becomes visible. One zone: the one where a compromise would hurt most, or where access is most chaotic. One conduit closed properly, for example the vendor’s remote access replaced by a controlled, logged path that someone switches on for a given intervention. One quarter. Then show the result at the site leadership meeting, in the site’s language: fewer ways in, a named owner, a procedure operations actually follows. The second zone is always easier than the first, and once it has been done the team knows it.

### “Fine. Show us how.”

Acceptance is the point at which the team can do the work, and what it needs now is method rather than persuasion. A peer example, ideally from a comparable site in the group, because an automation engineer believes another automation engineer faster than a consultant. A named owner for each zone, from operations or engineering rather than “IT”. And a place for security inside the existing work processes (change control, periodic review, supplier qualification) so that it outlives the project. Cosman makes the same point: run as a project, cybersecurity does not last; like safety, it has to become part of normal procedures.

The pressure behind the standard

Tell the team why the standard is arriving now, because “group wants it” only feeds denial. The NIS2 Directive, Directive (EU) 2022/2555, was adopted on 14 December 2022 and entered into force in January 2023. Its Annex I lists manufacturers of basic pharmaceutical products and pharmaceutical preparations (NACE division C21) in the health sector, and its Annex II covers a wide range of other manufacturing. Member States had to transpose it by 17 October 2024 and apply their national rules from 18 October 2024; at the end of November 2024 the Commission opened infringement procedures against 23 of them for not having fully done so. Article 21 requires appropriate and proportionate technical, operational and organisational measures, taking into account relevant European and international standards.

The directive does not name 62443, and it does not need to. For the control systems of a plant, the 62443 series is the obvious place to look for “relevant international standards”, and a group that picks it gives every site the same answer, whatever stage its own country’s law has reached. Put that way on Monday morning, the standard stops looking like a corporate whim.

Where to start

1. Listen first, and write the sentences down. They tell you which stage each part of the team is in, and they are the objections you will answer in writing later.
2. Walk one line with the people who run it. Build the boundary inventory together, then agree a one-page glossary from the standard’s terms to the site’s, with operations and QA.
3. Pick one zone and set its target from the consequence. Run the 62443-3-2 sequence on a single system: zones, conduits, risk, target security level, requirements specification.
4. Decide the exceptions. Every “not applicable” gets a rationale, a compensating measure, an owner and a review date, approved by the asset owner.
5. Put security into the procedures that already exist (change control, periodic review, supplier qualification), then show the first result and start the second zone.

Two things to avoid on the way. Do not hand the programme to IT alone: a compromise has process consequences, and the risk assessment needs the people who know what the line does when a controller misbehaves. And do not run it as a project with an end date. The assessment ends; the exposure does not.

What the lead is really managing

A new OT security standard is a technical document, but its first months on a site are a human process: people defending a way of working that has kept a line running safely for years. A lead who listens for the sentence, answers the stage the team is actually in and keeps the first step small will often find that the senior process engineer who said “this was written for refineries” turns into the best owner the first zone could have.

What people resist is losing control of their plant. Give them control of the first zone, and they will carry the rest.

References

• Eric C. Cosman, “Cybersecurity risk is the great equalizer”, InTech, ISA, May/June 2020, pp. 16–21, ISA InTech archive
• IEC 62443-3-2:2020, Security risk assessment for system design, edition 1.0, 24 June 2020, webstore.iec.ch
• IEC 62443-3-3:2013, System security requirements and security levels, edition 1.0, 7 August 2013, webstore.iec.ch
• Directive (EU) 2022/2555 (NIS2 Directive) of 14 December 2022, OJ L 333, 27 December 2022, eur-lex.europa.eu