Preemptive Cybersecurity for the Connected Pharma Plant

What Preemptive Means for a Validated Plant

The word “preemptive” is getting a lot of attention in security circles. In September 2025, Gartner forecast that by 2030, preemptive cybersecurity solutions will account for 50% of IT security spending, up from less than 5% in 2024. Gartner describes these technologies as ones that use AI and machine learning to anticipate and neutralize threats before they materialize, including predictive threat intelligence, advanced deception, and automated moving target defense.¹ The same release predicts more than one million documented vulnerabilities (CVEs) by 2030, up from about 277,000 in 2025.¹

That forecast is about IT security spending in general. It is worth knowing, because the tools your security team buys over the next five years will be sold under this label. But a pharmaceutical plant is not a typical IT estate, and most of what makes a plant safer before an attack has nothing to do with AI. On a plant floor, the most useful preemptive work is plain: know what is connected, cut the paths that do not need to exist, control who can reach in from outside, and watch the traffic that remains. None of it is new. What is new is how many more connections a modern plant has, and how many of them nobody has documented.

The Threat Picture Is Not Hypothetical

Dragos, an industrial cybersecurity firm, publishes an annual review of threats to operational technology (OT), meaning the control systems, instruments, and equipment that run physical processes. Its 2026 review, covering 2025, reported the following.²

Two caveats matter. First, “manufacturing” in the Dragos data covers all industrial manufacturing, not pharmaceuticals alone. Second, the report does not break out pharma plants as a separate group, so there is no sector-specific number to quote. The pattern still applies. Dragos also noted that OT incidents are often mislabeled as “IT only” because engineering workstations and human-machine interfaces (HMIs) run Windows and get classified as IT assets.² Anyone who has sat through an incident review at a plant will recognize that problem.

The best-documented pharma case is still the 2017 NotPetya attack on Merck. According to the New Jersey Appellate Division’s 2023 opinion in Merck’s insurance dispute, attackers had gained access to the update system of M.E. Doc, an accounting program used by companies doing business in Ukraine, and sent malicious updates through the normal update channel. Merck’s server in Ukraine received those updates. Once NotPetya started running, about 10,000 machines in Merck’s global network were infected within ninety seconds, about 20,000 within five minutes, and more than 40,000 in total. Merck contended the attack caused production facilities and critical applications to go offline and disrupted manufacturing, research and development, and sales.³ The court affirmed that the insurers’ “Hostile/Warlike Action” exclusion did not apply; the coverage in dispute at that stage was $699,475,000.³

Why the Connected Plant Is Harder to Defend

NIST Special Publication 800-82 Revision 3, the U.S. government’s main guide to OT security, lists the ways OT differs from IT. Several of them explain why ordinary IT security habits fail on a plant floor.⁴

• Equipment lives longer. NIST notes that typical IT components last three to five years, while OT is often in service for 10 to 15 years and sometimes longer.⁴ A 2012 control system is still running batches today.
• Updates need planning and testing. NIST says OT software updates need thorough testing by both the vendor and the end user, outages must be scheduled days or weeks ahead, and the OT may require revalidation as part of the update.⁴ That last point is the one pharma teams feel most.
• Support often comes from one vendor. NIST notes that third-party security tools are sometimes not allowed under OT vendor licensing and service agreements, and support can be lost if unapproved software is installed.⁴
• Old operating systems persist. Many OT systems run operating system versions that the vendor no longer patches.⁴

The FDA’s June 2025 white paper on manufacturing OT describes the same problem from the agency’s own experience. It notes that OT has historically been designed to prioritize consistent functionality over cybersecurity, and it names two core issues: lack of visibility (organizations often do not have an accurate inventory of what is on the network and how each device communicates) and lack of control (equipment may connect to other devices or a vendor’s home server in ways that are not disclosed and cannot be changed by the user).⁵

Put together, the plant has more connections than before, fewer people who understand all of them, equipment that cannot be patched on an IT schedule, and a validation regime that makes every change slower. A preemptive program is designed around those facts rather than against them.

The Regulatory Picture in 2026

No single regulation tells a pharma plant exactly how to secure its OT. Instead, several instruments overlap. It helps to be precise about what each one is and what status it has, because vendor marketing often blurs the line between binding rules, drafts, and white papers.

What FDA Has Said

FDA’s cGMP rules for drugs do not use the word “cybersecurity,” but 211.68(b) has always required that only authorized people can change records through computer systems.⁶ An attacker who reaches a controller or a batch record system is, by definition, an unauthorized person making changes. That makes access control on plant systems a GMP matter, not only an IT one.

The June 2025 white paper, issued by FDA’s Office of Regulatory and Emerging Science in the Office of the Chief Scientist, is the agency’s most direct statement on manufacturing OT. It is explicit that medical device cybersecurity is handled by other FDA programs and is not its subject.⁵ The paper describes a demonstration manufacturing line FDA built, which is not used to make any products, and the security practices it followed: NIST publications including SP 800-82, CISA guidelines, and strict network routing rules. It notes that many commercial off-the-shelf products may not natively comply with those requirements and may need reconfiguration.⁵ One line in the paper is worth showing to any executive team: “Much like quality assurance programs, strong cybersecurity processes are one of the pillars that support the safe, effective, and reliable production of medical products.”⁵

The white paper also acknowledges the tension this article is about. It says FDA’s regulatory frameworks include requirements for updating equipment or processes when issues such as cybersecurity vulnerabilities are discovered, but that business needs, lack of visibility into software, or other conditions can delay a manufacturer from updating.⁵ In other words, FDA does not treat validation as a reason to leave a known vulnerability in place.

What the EU Draft Annex 11 Would Add

The 2011 Annex 11 is short on security detail. Section 12 says physical and/or logical controls should restrict access to authorized persons and that the extent of controls depends on the system’s criticality.⁷ The draft revision, recommended jointly by the EU GMP/GDP Inspectors Working Group and the PIC/S Committee and published for consultation in 2025, is far more specific. Its Section 15 includes these expectations, among others:⁸

• Networks should be segmented, with firewall rules defined “as strict as practically feasible,” and firewall rules should be reviewed periodically because they tend to change or become insufficient over time (15.8 and 15.9).
• Validation of applications on updated operating systems and platforms should be planned and completed before the vendor’s support expires (15.11).
• Applications on unsupported or unpatched platforms are described as highly vulnerable and should be isolated from computer networks and the internet (15.12 and 15.14).
• USB and other bidirectional devices should be strictly controlled, and unused ports on critical servers and computers deactivated, blocked, or removed (15.15 to 15.17).
• Remote authentication on critical systems from outside controlled perimeters should include multifactor authentication (11.6).

NIS2 and the Cyber Resilience Act

For companies with EU operations, NIS2 is the broader legal driver. The European Commission’s summary notes that member states had until 17 October 2024 to transpose the directive, that medium-sized and large entities in covered sectors must take cybersecurity risk-management measures and notify significant incidents, and that the directive introduces accountability of top management for non-compliance.⁹ A DLA Piper analysis for life sciences explains that NIS2 applies to manufacturers of basic pharmaceutical products and pharmaceutical preparations and to entities doing research and development of medicinal products, and summarizes the three-stage reporting sequence: an early warning within 24 hours, a fuller notification within 72 hours, and a detailed report within one month.¹⁰ Whether a given company is treated as an essential or important entity depends on its size and on national transposition, so this needs a legal read for your specific footprint.

The Cyber Resilience Act points at your suppliers rather than at you. It entered into force on 10 December 2024, its main obligations apply from 11 December 2027, and reporting obligations have applied since 11 September 2026.¹¹ Since that date, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents, with an early warning within 24 hours and a full notification within 72 hours.¹² For a plant, that is useful: equipment and software vendors selling into the EU now carry a formal duty to report exploited flaws in their products. Your procurement and supplier-quality processes should ask how each vendor will pass that information on to you.

Build a Definitive Record of What Is on the Network

Every other control depends on this one. You cannot segment what you have not mapped, you cannot restrict vendor access to devices you did not know existed, and you cannot monitor for unusual traffic without knowing what normal traffic looks like.

In August 2025, CISA and partner agencies from the U.S., Australia, Canada, Germany, the Netherlands, and New Zealand published joint guidance on OT asset inventory. It defines an asset inventory as an organized, regularly updated list of an organization’s systems, hardware, and software, and recommends building an OT taxonomy that classifies assets by function and criticality.¹⁴ The guidance lays out a sequence: define scope and objectives, identify assets, collect attributes, create a taxonomy, manage the data, and manage the asset life cycle.¹⁴ Its worked examples come from oil and gas, electricity, and water, not pharma, so a plant will need to build its own taxonomy. The following month, CISA and the UK National Cyber Security Centre, with other partners, published guidance on creating and maintaining a “definitive record” of OT architecture that builds on the inventory work and covers both new and existing sites.¹⁵

Why a Pharma Inventory Is Harder Than It Looks

Most pharma sites already have an inventory of computerized systems. The 2011 Annex 11 says: “An up to date listing of all relevant systems and their GMP functionality (inventory) should be available.”⁷ The trouble is that the GMP inventory is organized by system, while an attacker sees the network by device. A single “filling line” entry in the validation inventory may hide a dozen networked components from several makers.

The FDA white paper makes exactly this point. It notes that a piece of equipment for one unit operation, such as chromatography or a bioreactor, may contain embedded control and automation devices from another manufacturer, and that a branded controller from one vendor may be embedded in equipment from a second vendor while relying on software from a third to talk to the manufacturing execution system.⁵ It recommends asking vendors for a hardware bill of materials and a software bill of materials (SBOM) so the integrating team knows exactly what it is installing.⁵

What to Record for Each Asset

A useful plant inventory combines security attributes with GMP attributes, so the same record can drive both risk decisions and change control. At a minimum, record:

• Device type, maker, model, firmware and software versions, and the parent system or skid it belongs to.
• Network location, addresses, and every known communication path in and out, including any connection to the vendor.
• GMP impact: whether the device controls, records, or displays data that affects product quality or batch release.
• Validation status and the change control owner.
• Vendor support status, including published end-of-life dates.
• Who can access it, locally and remotely, and how.

Once built, the record has to stay current. The simplest way is to make “update the OT asset record” a required step in every change control that touches plant equipment or networks, rather than a separate project that goes out of date the month after it finishes.

Segment the Plant Into Zones and Conduits

Segmentation is the control that would have limited NotPetya’s spread, and it is the one both CISA and the draft Annex 11 put near the top of their lists. CISA’s May 2025 fact sheet on primary OT mitigations recommends segmenting IT and OT networks and introducing a demilitarized zone (DMZ) for passing control data to enterprise systems, which reduces the risk of disruption to essential OT operations.¹⁶

The Zones and Conduits Model

The standard vocabulary comes from the ISA/IEC 62443 series, the main international standards family for industrial automation and control system security. ISA describes the series as covering security for industrial automation and control systems across sectors, with requirements for four groups: asset owners, automation product suppliers, integrators, and service suppliers.¹⁷ Its parts include 62443-2-1 (security program requirements for asset owners), 62443-3-2 (security risk assessment for system design), 62443-3-3 (system security requirements and security levels), 62443-2-4 (requirements for service providers), and 62443-4-1 and 4-2 (secure product development and component requirements).¹⁷

The FDA white paper explains the model in plain terms. A zone is a collection of assets that have common security requirements. Conduits allow and control communication between zones. Under least privilege, assets communicate only within their zone unless a defined policy allows traffic through a specified conduit.⁵ Its example is directly relevant to pharma: a facility with multiple fill-finish lines. Equipment on one line has no need to talk to equipment on another, although product and capacity information may pass between them. Putting each line in its own zone, with specific conduits, limits the effect if one line is compromised.⁵ The paper adds that this approach requires an accurate inventory of connected assets and a clear understanding of their communication needs, which is why the inventory comes first.⁵

This is an illustration, not a reference design. Your zones should follow your process and your risk assessment. A biologics suite, a small-molecule packaging hall, and a QC laboratory will each group differently.

Segmentation Changes Are GMP Changes

Moving a validated system onto a new VLAN, adding a firewall between two zones, or tightening a firewall rule can break a data flow that the validation depends on: a scale sending weights to the batch record, a historian collecting critical process parameters, or an audit trail being written to a central server. That is why segmentation projects at pharma sites stall. The fix is to plan them as GMP changes from the start:

• Map every data flow each validated system needs before you move it, using the inventory.
• Test the new rules in a non-production environment or during planned downtime.
• Verify after the change that each GMP data flow still works, with objective evidence (a test batch record, a historian trend, an audit trail entry).
• Record the firewall rule set as a configuration item under change control.

The draft Annex 11 expects firewall rules to be reviewed periodically because ports get opened and never closed.⁸ That review is easy to add to the periodic review you already perform for each validated system, since the 2011 Annex 11 already lists security among the items periodic evaluation should consider.⁷

Put Vendor Remote Access Under Your Control

Equipment vendors need to reach their systems. They diagnose faults, adjust recipes, and support qualification. Many plants have accumulated years of vendor connections: a modem in a control cabinet, a remote desktop tool installed during commissioning, a VPN account shared by a vendor’s whole service team. Each one is a way into the plant that bypasses whatever segmentation you built.

What the Agencies Recommend

CISA’s May 2025 fact sheet says many organizations, or contractors working for them, make risk-based trade-offs when implementing remote access to OT, and that those trade-offs deserve careful reevaluation. If remote access is essential, CISA recommends a private IP network connection, a VPN with a strong password and phishing-resistant multifactor authentication, remote access configured for least privilege by asset and role, and disabling dormant accounts.¹⁶

NIST SP 800-82 adds that remote access should be provided only if justified and limited to what the business need requires, that it should not circumvent safety or security controls, and that multifactor authentication should be considered. It recognizes that temporary remote access for vendor maintenance is sometimes needed and says procedures should still be followed to ensure secure connections.⁴ The FDA white paper makes a related point about integration teams, which may include short-term contractors or vendor staff: they should be held to the same security training and standards as permanent staff, and temporary privileged accounts should be removed automatically, with confirmation, when deployment work ends.⁵

A Workable Remote Access Standard for a Plant

Tie this to your quality agreements. If a vendor changes a validated configuration during a remote session, that is a change to a GMP system. It must go through your change control, not the vendor’s service ticket. Put that in writing in the supplier agreement, and make sure the site team understands that approving a remote session does not approve a configuration change.

Live With Legacy Equipment You Cannot Patch Yet

Every established plant has equipment running an operating system its maker stopped supporting years ago. Sometimes the equipment vendor has not qualified its software on a newer version. Sometimes the vendor no longer exists. Replacing the equipment means capital, requalification, and possibly a regulatory filing. So the old workstation stays.

This is normal, and regulators know it. What they expect is that you know which systems are in this state and have done something deliberate about each one. NIST SP 800-82 calls for a systematic, accountable, and documented OT patch management process that covers how to monitor for patches, when to apply them, how to test them (with vendors or on offline systems), and how to select compensating controls to limit exposure when patching is delayed.⁴ It also warns that a patch can remove a vulnerability and still create a greater production or safety risk, which is why regression testing is advised.⁴

Even when you want to patch, a fix may not exist. Dragos determined that 25% of ICS-CERT and NVD vulnerabilities in 2025 had incorrect severity (CVSS) scores, and that 26% of advisories contained no patch or mitigation from vendors.² So a plant cannot simply patch everything scored “critical.” It needs its own way to decide what matters.

Deciding What to Fix First

A practical triage for plant vulnerabilities weighs three things: whether the vulnerability is known to be exploited, whether the affected device is reachable from outside its zone, and what the device does to product quality. CISA’s Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of active exploitation and is a better first filter than severity scores alone.¹⁸ A known-exploited flaw on a reachable device that controls a critical process parameter goes to the top. A theoretical flaw on an isolated display that shows non-GMP data can wait for the next planned outage.

The isolation approach in the table matches where the draft Annex 11 is heading. It says applications on unsupported platforms are highly vulnerable and should be isolated from computer networks and the internet, and that validation on updated platforms should be planned and completed before the vendor’s support expires.⁸ That second expectation is a planning discipline more than a security control: it means your validation calendar has to track vendors’ end-of-support dates, which is one more reason to record those dates in the inventory.

Monitor Without Disturbing the Process

Preventive controls reduce the number of ways in. Monitoring shortens the time an attacker stays once inside. The Dragos numbers show why that matters: organizations with comprehensive OT visibility detected and contained OT ransomware incidents in an average of 5 days, against an industry-wide dwell time of 42 days.² These are Dragos’s figures rather than a controlled study, so read them as indicative, but the direction is clear.

Start Passive

NIST SP 800-82 makes a point that works in a plant’s favor: OT traffic is typically more deterministic, meaning repeatable, predictable, and designed, than IT traffic, so unusual behavior is easier to spot. It recommends understanding the normal state of the OT network first, and says running monitoring in a passive (listen or learning) mode may be a necessary first step.⁴ It notes that network monitoring in OT is typically deployed using switched port analyzer (SPAN) ports or passive network taps, and that host-based monitoring on HMIs, SCADA servers, and engineering workstations should be added only where it does not harm performance or safety.⁴

Passive monitoring suits a validated plant because it does not send traffic to production devices. It listens to a copy of the traffic. That keeps the monitoring tool outside the validated boundary of the systems it watches, in most cases, although you should still document that conclusion in a risk assessment and check that installing a tap or enabling a SPAN port is itself done under change control.

Be Careful With Automated Blocking

Intrusion prevention systems can block traffic automatically. On an office network that is useful. On a plant network, a false positive that blocks a controller’s traffic can stop a batch. NIST advises considering the effect of automated responses before deploying them in OT, and suggests placing prevention systems at higher levels, such as the DMZ interfaces, to limit the chance of disrupting operations.⁴ For most pharma sites, a sound starting position is: detect everywhere, block automatically only at the DMZ, and respond inside production zones through a human decision made with operations.

Close the Loop With Quality

Monitoring produces alerts, and some alerts are GMP events. An unexpected connection to a batch record server, an engineering workstation pushing a new program to a controller outside a change window, or a new device appearing in a line zone may each mean a validated system’s state has changed. Agree in advance, between security, engineering, and quality, which alert types trigger a deviation assessment. The 2011 Annex 11 already says all incidents, not only system failures and data errors, should be reported and assessed.⁷ Build that into the security runbook so the response does not depend on who happens to be on call.

Fit Cyber Controls Into Validation and Change Control

This is where most plant security programs fail. Security teams want to patch monthly and change firewall rules in hours. Quality teams need evidence that each change keeps the validated state. When the two sides meet only at the change control board, every security change becomes a negotiation, the backlog grows, and eventually someone decides the plant is “too hard” and leaves it alone. That is the opposite of preemptive.

The answer is not to exempt security changes from change control. The 2011 Annex 11 requires that any change to a computerized system, including configuration changes, be made in a controlled manner under a defined procedure.⁷ The answer is to do the risk assessment once, in advance, for each recurring type of security change, and define the verification each one needs. Then individual changes can move quickly because the thinking has already been done and approved.

Pre-Assessed Change Categories

These categories are examples. Your categories should come from your own risk assessments and match your change control SOP. The point is that each row is decided once, documented, and approved by quality, so the plant does not have to hold a full debate for every monthly patch.

Use the Evidence You Already Generate

Much of the verification a security change needs is evidence the plant already produces. A batch record that completes normally, a historian trend with no gaps, an audit trail entry written with the correct user and timestamp: each of these shows a GMP data flow is still working. Define in advance which of these counts as verification for each change category, and security changes stop needing bespoke test scripts.

Buy Security In, Instead of Adding It Later

The easiest time to secure plant equipment is before the purchase order. In January 2025, CISA and partner agencies from several countries, with a contribution from the European Commission’s DG CONNECT, published guidance on what OT owners should ask vendors when selecting products. It warns that attackers who compromise OT components tend to target specific products rather than specific organizations, and that many OT products have weak authentication, known vulnerabilities, limited logging, insecure defaults, and insecure legacy protocols.¹⁹ It lists twelve areas to evaluate, among them configuration management, logging in the baseline product, secure defaults, strong authentication, vulnerability management, and upgrade and patch tooling.¹⁹

Its questions on patching are the ones most relevant to pharma. The guidance suggests asking whether the maker tests patches and reports the results, whether it updates software to modern operating systems when the old one reaches end of life, whether it publishes end-of-life dates, whether buyers can verify an update is authentic, and whether patches are free and delivered over secure channels.¹⁹ The FDA white paper makes a similar point from the buyer’s side: if a security feature is missing, ask the vendor to add it, since vendors may not know what customers want until enough of them ask.⁵

Each of these can be tested during factory and site acceptance testing, which means security becomes part of qualification rather than a separate project after go-live.

A 90-Day Starting Sequence

For a site that has not yet started, a realistic first quarter looks like this. It does not require new tools on day one.

Conclusion

A preemptive program for a connected pharma plant is mostly disciplined engineering and quality practice applied to the network. Know every asset and how it communicates. Separate what does not need to talk. Make every vendor connection visible, named, and time-limited. Isolate the legacy systems you cannot yet replace, and track them against a plan. Watch the traffic passively and agree ahead of time which alerts are GMP events. Then make all of this workable inside change control by deciding the recurring changes once, with quality, instead of arguing each one. The threat data shows attackers are already inside industrial networks for weeks at a time. The regulatory direction, from FDA’s white paper to the draft Annex 11 and NIS2, shows inspectors and legislators expect plants to act. Neither requires waiting for a final text.

Sakara Digital works with pharma and biotech organizations on the point where plant technology, validation, and quality systems meet. If you are working out how to secure a connected site without putting your validated state at risk, and want an independent view on where to start, we are happy to have that conversation.

For Further Reading