Zscalerのブログ
Zscalerの最新ブログ情報を受信
Pharma Is Building Again. It’s Time to Put Security in the Blueprints.
The onshoring wave is a once-in-a-generation chance to build connected, AI-ready plants the right way. In a GMP plant, most of the security decisions are effectively made before the first batch runs.
Somewhere in North Carolina, Indiana, or Pennsylvania this year, a field is turning into a pharmaceutical plant. In a construction trailer at the edge of the site sits a thick binder of user requirements, the document that says what every system in the plant must do. Engineers are signing off on drawings for bioreactor suites and fill-finish lines, and equipment vendors are building skids in their own factories hundreds of miles away. In a few years the site will make medicines that patients depend on, and it will probably still be running long after everyone who designed it has retired.
Why now? Mostly pressure. The pandemic showed how much of the US drug supply depends on factories overseas. In 2025 Washington followed with an executive order to speed up approvals for domestic plants, and with the threat of steep tariffs on imported branded drugs from companies that were not building in the US. Drugmakers responded. They announced more than $370 billion in planned US investment during 2025, according to DPR Construction's year-end tally. Not all of it is manufacturing, since the pledges also cover R&D and partnerships, but a large share is concrete, steel, and cleanrooms.
A new plant is not a quick project. PhRMA puts it at 5 to 10 years and up to $2 billion from decision to production. Regulators are getting involved earlier as well. FDA's PreCheck pilot is open only to eligible new facilities, and it reviews facility design and equipment qualification before a plant runs its first batch.
For the engineers designing one of these plants, that long runway is also a rare chance to start over. They get new equipment, new automation, and a data architecture built for how plants will run in the 2030s rather than how they ran in the 1990s.
Security belongs on that list too, and that is a newer idea than it sounds. For most of the industry's history, plant security meant walling the plant network off from the rest of the company and the internet, and hoping the wall held. Three things have changed that:
- The wall did not hold. In 2017, NotPetya reached Merck through a compromised software update rather than a breach of the plant perimeter. It spread across the company's network, infected more than 40,000 computers, and disrupted manufacturing. The company put the losses at $1.4 billion.
- A walled-off plant cannot do what it is being built for. These plants are funded on the promise of AI and analytics, and those depend on data leaving the plant floor.
- Regulators now expect security in the design. Draft updates to the EU's GMP rules ask for segmented networks, controlled remote access, and security requirements written into a system's specification before it is qualified.
What are these plants being built to do?
These are not copies of the plants they replace. Most are being designed around what ISPE calls Pharma 4.0, an operating model for bringing Industry 4.0 into regulated manufacturing. In practice that means:
- continuous manufacturing in place of batch-and-hold, now covered by ICH Q13
- process analytical technology (PAT) that measures quality in the line instead of waiting on the lab
- digital twins that let engineers test a process change before they touch the equipment
AI is where much of the payoff is expected:
- Catching deviations early. Models flag a drifting batch from sensor trends before it is lost, instead of leaving an investigation for afterwards.
- Faster batch release. PAT data, batch records, and lab results come together, so Quality reviews by exception.
- Predictive maintenance. It focuses on the equipment that sets a plant's capacity, such as lyophilizers, isolators, and bioreactors.
Every one of those benefits depends on the same thing. A model cannot flag a drifting batch if it never sees the sensor data. Quality cannot review by exception if the PAT results and the batch records sit in separate systems that never talk to each other. The value comes from data moving: from the skid to the historian, from the site to the cloud, and between the plant and its partners. A plant designed to be walled off cannot deliver any of it.
That changes what a plant's IT looks like. Some systems have to stay close to the production line, because a plant must keep making product even if its internet link goes down. The systems that run and release each batch therefore live on site or nearby. That includes the manufacturing execution system (MES), which enforces each recipe step by step, and the local ERP instance, often SAP, that releases finished product.
The heavy analytics go the other way. Training a model on years of batch data from a dozen sites takes cloud-scale computing, and it needs every site's data in one place. So a new plant ends up hybrid by design, partly on site and partly in the cloud, and connected all the time.
That is the real opportunity. ISPE's Pharma 4.0 model already names data integrity by design as one of its two core enablers. Security by design is the same idea applied to the network. The question for a new plant is not how to keep it disconnected. It is how to connect it the right way, so that the AI business case and the security case become the same design.
There is a catch, though, and it arrives on a schedule.
So why does the window close so early?
In most factories, security is something you can add later. A segmentation project or a new remote-access tool is disruptive, but it is an IT change. A GMP plant is different. Once a system is qualified and the process is validated, almost any change to it goes through change control. The EU's draft revision of GMP Annex 11 is explicit about it. A significant change that could affect product quality, patient safety, or data integrity "should be subject to re-qualification and validation."
That is why so much pharma OT still runs old software with known vulnerabilities, even though plant teams are usually well aware of them. The security fix itself is rarely the expensive part. Re-running qualification on a system that is busy making product is.
So for a new plant, the security architecture becomes hard and expensive to change once the plant is qualified. Changes are still possible, through impact assessment and, for significant ones, requalification, but few teams take that on lightly. Whatever is on the network when performance qualification is signed, every shared login and every vendor modem included, is what the plant is likely to run with for years.
The same Annex 11 draft also adds a full security section. It covers segmented networks with strict firewall rules, timely patching, isolation of unsupported systems, and USB ports deactivated by default. It also says the user requirements specification (URS) should include security requirements and data flow diagrams. The consultation closed in October 2025, and the final text is still pending. Requirements like these are far cheaper to meet in a design document than in a change request.

The top row is how most plants get security today: a review after go-live, findings that land in change control, and a choice between revalidation and an accepted risk. The bottom row moves the same requirements into the URS. They are then checked at the factory and site acceptance tests (FAT and SAT), the vendor-shop and on-site checks every system goes through. Finally they are proven in installation, operational, and performance qualification (IQ, OQ, and PQ) alongside the system they protect.
What belongs in the URS?
Not everything. Controls inside the validated systems themselves are usually best left to the automation vendor and Quality. The six requirements below are the ones that get decided by default if nobody writes them down. Each is cheap to write into the URS and test at FAT, and expensive to add after PQ. The examples use a biologics plant with fill-finish, but the same six apply to most new drug substance or drug product sites.
Requirement 1: A named identity for every person and every machine.
For people, the regulations already require it. 21 CFR 11.10(d) requires limiting system access to authorized individuals, and 11.100(a) requires every electronic signature to be unique to one person. The draft Annex 11 goes further: it calls any shared account that can change data a violation of data integrity. Yet shared operator logins on skid HMIs are still common, because the package unit arrived with one built-in account.
Design it out up front. Write named, directory-backed identity for every HMI, engineering workstation, and batch client into the user requirements, so that each OEM has to deliver it at FAT. The regulations stop at people, but the same logic holds for machines, so extend the rule to everything that is not a person:
- MES-to-skid integrations that download recipes and collect batch data
- historian collectors that poll every controller on the floor
- service accounts used by backup, patching, and monitoring tools
- AI agents that read process data for analytics and maintenance models
A new plant will connect more machine identities to batch data than humans. Map which of them can reach the electronic batch record, laboratory information management system (LIMS), and process historian before go-live. That map is the access baseline the plant will be held to.
Requirement 2: Zones drawn around unit operations, not Purdue levels.
A biologics plant is a collection of package units: bioreactors, chromatography and filtration skids, clean-in-place and steam-in-place (CIP and SIP) systems, isolators, and lyophilizers. Each comes from a different OEM with its own controller, HMI, and network habits. Many plants follow the Purdue reference model by putting all of them in one shared Level 1-2 network. In practice, that network often becomes flat the day the integrator connects the last skid. Once it is flat, anything that compromises one skid, such as an infected vendor laptop plugged into a CIP panel, can reach every other skid, including the bioreactors running product.
Start by finding everything. You cannot draw a zone around an asset nobody has inventoried, and package units often arrive with more networked devices than the drawings show. Then zone the plant the way the process is built, using the zones and conduits model from ISA/IEC 62443. Each unit operation gets its own zone. The only conduits are the ones the batch actually needs: recipe download from the batch engine, alarms and data up to the historian, and electronic batch record entries to MES. The cleanroom building management and environmental monitoring systems get their own zone too. They are GMP-relevant, because pressure differentials and particle counts are product-quality data, but they are installed by a different contractor on a different schedule.
Requirement 3: One brokered path for every vendor.
Picture SAT week. The skids have arrived, and a dozen vendor engineers are on site, each with a laptop, a deadline, and a preferred way in. The automation lead's job that week is to get every system through testing, not to referee remote access.
After handover, most OEMs still expect remote support for the life of the equipment. If the plant has not designed that path, each vendor brings their own: a cellular router in the panel, a remote-desktop tool on the HMI, or a VPN nobody inventories. Once qualified, those paths are part of the validated state and very hard to remove.
The alternative is to qualify one brokered path that every vendor uses from the first site acceptance test (SAT). Access is tied to a named person and limited to a single asset. It is approved per session, recorded, and closed when the work ends. The vendor never gets a network route into the plant, only a session to the asset they support. The draft Annex 11 already expects multifactor authentication for remote access to critical systems from outside the site. Write the lifecycle into the vendor contracts as well, so that access granted during commissioning is reviewed at handover and expires unless the plant renews it.

Zones follow the process, not the Purdue floor. The vendor's dashed path ends at one asset in one zone; it never becomes a route into the plant.
Requirement 4: Every inbound file inspected before it reaches a validated system.
New plants ingest a steady stream of files. These include recipe packages, OEM firmware and patches, validation protocols, and tech transfer documents from development sites or contract partners. Most arrive by email, file share, or the vendor's laptop, and some still arrive on USB.
Route files through a single transfer path that detonates and inspects them before they reach anything validated. Removable media is the honest gap here, since no network control sees a USB stick. The draft Annex 11 is blunt about it: USB use should be strictly controlled, outside media scanned before use, and ports on critical systems deactivated by default. The plant should give vendors a better path than USB from day one, so that locking the ports during qualification is practical.
Requirement 5: Outbound data classified and inspected.
The most valuable data in a pharma plant is the process: process parameters, batch genealogy, and the analytical methods that prove the product is what the label says. New plants are being built to stream that data out to cloud analytics, digital twins, and AI models for process monitoring and predictive maintenance.
That outbound flow needs the same scrutiny as inbound access. Classify process and batch data at the source, and inspect what leaves the plant for where it is going. The EU's draft Annex 22, the first GMP text dedicated to AI, points the same way, with change control and human review for AI used in manufacturing.
Requirement 6: Early warning, response, and recovery.
A validated plant will always carry some known vulnerabilities, because patching a qualified system takes time even in a plant designed for it. That gap is getting more dangerous. Google's Threat Intelligence Group reported that monthly vulnerability disclosures roughly doubled during 2026, and that attackers are using AI to turn newly published flaws into working exploits faster. Attackers are moving faster, and a GMP plant's patch cycle is not keeping up. Prevention needs a backstop that tells the plant early, and with confidence, that someone is inside.
Advanced security capabilities such as deception provide that backstop. Decoy HMIs, engineering workstations, controllers, and credentials are placed in every zone, where no legitimate user or process ever touches them, so any interaction with one is a high-confidence signal.
That matters more as attacks become automated. Automated reconnaissance, AI-assisted or not, sweeps whatever it can reach, and that is exactly what a decoy is waiting for. Deception also suits a plant whose security team is often a handful of people rather than a 24x7 SOC.
Placed during design, decoys can mirror the real skids and the real zone layout, so they are indistinguishable from production assets. Added years later, they tend to look like what they are.
Detection is only the first step, so the URS should also say what happens next:
- Who hears about it. Alerts should reach both the plant's operations team and security.
- Quality's role. Quality needs a seat in the response whenever an event could touch a GMP system or a batch record, because Quality decides whether product is affected.
- The way back. The plant needs local access when the WAN is down. It also needs backups of control logic, configurations, and batch records that have actually been restored and verified. The draft Annex 11 already expects tested restores and a disaster recovery plan with a defined recovery time.

Files in, data out, and machine access each pass a check at the boundary. Removable media is the one path no network control sees, which is why the plant has to offer vendors something better than USB before qualification locks the ports.
What does doing it right look like?
Most existing plants collected security one problem at a time over twenty years: a firewall here, a remote-access tool there, each with its own rules and owner. A new plant can follow a different pattern. Every connection that crosses a boundary goes through a single policy layer: between zones, in or out of the plant, from a vendor, to the cloud, or from an AI system. That layer checks who or what is asking and grants access to a specific asset or application, never to the network around it. Control traffic inside a zone stays local, between the controllers and the systems that run the batch. Because the layer sits around the validated systems rather than inside them, the six requirements can be built and tested without modifying the systems themselves.
It is the same idea as data integrity by design, applied to access: decide the rules once, at design time, and make them provable.
The Zscaler Zero Trust Exchange is our implementation of that pattern. The six requirements map to one platform and one policy model. It can be verified at FAT and SAT and documented in the qualification package alongside the systems it protects.

Every way into or out of the plant passes through the same policy model, whether it is a person, a vendor, a file, a cloud service, or an AI agent. The table maps each connection to the Zscaler capability that covers it.
Connection | What it needs | Zscaler |
|---|---|---|
Engineers and operators | Identity-bound access to specific applications, never to the network | Zscaler Private Access; identity integration |
OEM vendors and CDMOs | Per-asset, approved, recorded sessions | Privileged Remote Access |
Files and updates | Detonation and inspection before delivery | Cloud Sandbox; sandboxed file transfer in PRA |
Cloud analytics and SaaS | Inline inspection, data classification, DLP | Zscaler Internet Access with Data Protection |
AI models and agents | Own identity, mapped and scoped access, AI usage controls | Zscaler Access Graph with AI security controls |
Inside the zones | Asset discovery and agentless segmentation by unit operation | Zero Trust Branch with device segmentation |
Early warning | Decoys in every zone | Zscaler Deception |
Site connectivity | Secure WAN and cellular links with no exposed edge devices | Zero Trust Branch; Zscaler Cellular |
What this does not replace is the control set on the validated systems themselves. That means audit trails in the MES, recipe locks in the batch engine, and the automation vendor's own hardening. It also does not solve removable media on its own. It gives the plant one enforceable layer around those systems, defined before qualification instead of negotiated after it.
The window is now
Back in that field, the drawings are still being signed and the binder in the trailer is still being written. The plant that comes out of them will make medicines for decades, run AI its designers have not imagined yet, and connect to partners that do not exist today. Whether it does that securely depends less on the tools bought in 2035 than on the requirements written this year.
Existing plants can still get there, through risk-based change control, one zone at a time, and we will cover that path in a follow-up. But for the plants being designed now, the cheapest security control is a line in the user requirements specification.
If you are planning a new site or expansion, the best time to bring us in is front-end engineering design (FEED), before the URS is frozen. Request an OT architecture workshop. You will leave with two things: a zone and data-flow map that your engineering and Quality teams have signed off, and a set of security requirements written to be tested at FAT and SAT. And hear from our customers directly on how they use Zscaler for OT security.
このブログは役に立ちましたか?
免責事項:このブログは、Zscalerが情報提供のみを目的として作成したものであり、「現状のまま」提供されています。記載された内容の正確性、完全性、信頼性については一切保証されません。Zscalerは、ブログ内の情報の誤りや欠如、またはその情報に基づいて行われるいかなる行為に関して一切の責任を負いません。また、ブログ内でリンクされているサードパーティーのWebサイトおよびリソースは、利便性のみを目的として提供されており、その内容や運用についても一切の責任を負いません。すべての内容は予告なく変更される場合があります。このブログにアクセスすることで、これらの条件に同意し、情報の確認および使用は自己責任で行うことを理解したものとみなされます。



