ISA-95 and ISA-99: The Complete Technical Guide to Industrial Automation Standards
The industrial control systems landscape is layered. Equipment talks to supervisory systems, which feed data to management layers, which feed production systems. ISA-95 codifies this hierarchy. ISA-99, now part of the IEC 62443 family, locks down the security zones between them. Together, they define how modern factories actually work—and where the attackers actually hide.
This post cuts through the standards’ dense terminology. You’ll learn the Purdue model’s five operational levels, the exact data structures ISA-95 uses to describe production, how ISA-99’s security zones redefine what “connected” means, and why the Unified Namespace (UNS) era is bending—but not breaking—the traditional stack.
Why ISA-95 and ISA-99 matter in 2026
The Purdue model is no longer optional for industrial facilities. Where it once described an ideal architecture, it now describes the minimum boundary between operational technology (OT) and information technology (IT). ISA-95 (American National Standard for Enterprise-Control System Integration) tells you what data lives where and how to move it. ISA-99, formally renamed to IEC 62443 (Cybersecurity for Industrial Automation and Control Systems), tells you how to defend the boundary itself. The two are inseparable: ISA-95 designs the topology, ISA-99 secures it.
Today’s pressure comes from two directions. First, Industry 4.0 demands tighter IT-OT integration—real-time MES data flowing to ERP, cloud analytics ingesting sensor streams, edge computing pushing logic down. Second, regulatory frameworks (NIST SP 800-82, grid standards, pharma GxP) now require both architectural clarity and provable defense depth. Companies that skip this work end up with islands of data, retrofitted security controls, and compliance failures.
The original ISA-95 thesis (1995) was architectural discipline. ISA-99 (2013) added the security layer. By 2026, Sparkplug B and the Unified Namespace have introduced a horizontal data-plane that bypasses some traditional Purdue hierarchy—yet the level abstraction remains the foundational security boundary. This post reconciles both worlds.
ISA-95: The Five-Level Hierarchy
ISA-95 defines production operations as five discrete levels, each with distinct responsibilities, latency constraints, and network isolation requirements. The standard doesn’t mandate any particular technology; it mandates separation of concerns.
Level 0 — Field: Sensors, actuators, and process equipment (PLCs, drives, process controllers). Cycle times: milliseconds to seconds. Network: real-time deterministic (Profibus, EtherCAT, Ethernet/IP). Data patterns: dense, time-series, continuous streams. Security model: physical isolation (locked cabinets, hardened controllers) or homogeneous trust (all devices factory-floor authorized).
Level 1 — Control: Supervisory control and data acquisition (SCADA), programmable logic controllers (PLCs), human-machine interfaces (HMIs), and edge gateways. Cycle times: 100 ms to seconds. Network: real-time or soft real-time (Modbus TCP, Profinet, OPC UA). Purpose: direct machine control, local decision logic, safety interlocks. Data: command execution, alarm states, immediate KPIs.
Level 2 — Supervision: Manufacturing Execution Systems (MES), real-time optimizers, production scheduling engines. Cycle times: seconds to minutes. Network: standard industrial Ethernet, VPN-protected gateways. Purpose: batch sequencing, recipe management, production-state tracking, downtime root-cause analysis. Data: part genealogy, downtime records, quality metrics, material lot assignments.
Level 3 — Planning: Enterprise Resource Planning (ERP), production planning, demand forecasting. Cycle times: minutes to hours. Network: corporate IT (HTTPS, OAuth, VPNs). Purpose: inventory allocation, financial reconciliation, capacity balancing, procurement triggers. Data: bill of materials (BOM), labor costs, supply-chain visibility, revenue impact.
Level 4 — Enterprise: Business Intelligence (BI), CRM, accounting, board dashboards. Cycle times: hours to days. Network: internet-connected, multi-tenant. Purpose: strategic insights, competitive positioning, stakeholder reporting. Data: aggregated KPIs, market trends, shareholder value.
The Purdue model enforces data-flow asymmetry: Level 2 pulls summary data up from Level 1 and pushes directives down. Level 0 never initiates communication with Level 3. This asymmetry is not a limitation—it is the security boundary itself.
The table below captures the latency and update-frequency expectations per level:
| Level | Name | Cycle Time | Network Paradigm | Typical Update Rate | Trust Model |
|---|---|---|---|---|---|
| 0 | Field | 1–100 ms | Real-time Ethernet / Fieldbus | Continuous stream | Physical security |
| 1 | Control | 100 ms–1 s | Real-time / Soft real-time | 10–100 Hz | Factory VLAN |
| 2 | Supervision | 1–60 s | Standard Ethernet (VPN) | Event-driven + periodic | Corporate firewall |
| 3 | Planning | 1 hour–1 day | HTTPS (internet) | Once daily / on-demand | OAuth + VPN |
| 4 | Enterprise | 1 day–1 month | Internet (public APIs) | Analytics query | Cloud IAM |
ISA-95 Parts 1–8: A Summary
The ISA-95 standard is split into eight documents:
- Part 1 (Models and Terminology): Defines the five levels, vocabulary, and use cases.
- Part 2 (Data Model): Object model: Resource, Material, Personnel, Equipment, Process Segment, Production Schedule, Production Performance. This is the what of production data.
- Part 3 (Activity Models): State machines for production workflows: Request → Prepare → Run → Complete → Close.
- Part 4 (Objects and Attributes): Detailed schemas for each object class (e.g., every field in a “Production Schedule” record).
- Part 5 (Security): Authentication, role-based access control (RBAC), audit trails. Aligned with IEC 62443 (ISA-99).
- Part 6 (Messaging): Exchange protocols for ISA-95 data: SOAP (legacy), REST, or B2MML XML.
- Part 7 (Batch Management): Specific workflows for batch-mode processes (pharma, food, chemicals).
- Part 8 (Compliance): Implementation guides and conformance profiles.
For most practitioners, Parts 1–2 and 6 (messaging) are operational; Parts 3–4 are reference; Part 5 is policy-driven by ISA-99.
ISA-95 Object Model: The Core Data Structures
ISA-95 Part 2 defines seven core object classes. Every production operation is composed of instances of these:
Resource: Any consumable or reusable input—raw material, labor, energy, gas. Attributes: ID, classification, location, quantity available, unit of measure.
Material: Raw material or in-process inventory. Tracked via lot/batch number. Attributes: ID, test results, supplier, expiration, genealogy.
Personnel: Human actors. Attributes: ID, role, qualification, shift assignment, time-in-role.
Equipment: Machines, tanks, packaging lines. Attributes: ID, serial number, OEE (overall equipment effectiveness), maintenance schedule, current utilization.
Process Segment: A unit operation (mixing, heating, packaging). Defined by inputs, outputs, and timing. Attributes: ID, parent process, recipe version, expected duration, expected input/output quantities.
Production Schedule: A plan for executing process segments. Attributes: ID, start time, end time, required resources, material lot assignments, sequence dependencies.
Production Performance: Actual results from a production segment. Attributes: ID, actual start/end time, actual input/output quantities, downtime events, quality measurements.
The data model is intentionally generic. It doesn’t prescribe how a facility runs (continuous, batch, mixed-mode, pull-based, push-based); it prescribes what must be recorded regardless of mode.
B2MML and ISA-95 Messaging: The Data Exchange Layer
ISA-95 Part 6 specifies how to serialize these objects and send them over a network. The original binding was SOAP; modern practice uses REST APIs or B2MML (Business-to-Manufacturing Markup Language)—an XML schema representation of ISA-95 objects.
B2MML Structure
B2MML maps every ISA-95 object to an XML element. Example: a Production Schedule request from MES to SCADA-level controller:
<?xml version="1.0" encoding="UTF-8"?>
<ProductionSchedule xmlns="http://www.mesa.org/xml/B2MML">
<ID>SCHED-20260422-0001</ID>
<StartTime>2026-04-22T06:00:00Z</StartTime>
<EndTime>2026-04-22T14:00:00Z</EndTime>
<HierarchyScope>
<EquipmentID>REACTOR-01</EquipmentID>
</HierarchyScope>
<ProcessSegment>
<ID>MIX-BATCH-42</ID>
<ExpectedDuration>PT02H30M</ExpectedDuration>
<Material>
<ID>RAW-TOLUENE-LOT-2026-001</ID>
<Quantity>500.0</Quantity>
<UnitMeasure>KG</UnitMeasure>
</Material>
<Equipment>
<ID>REACTOR-01</ID>
</Equipment>
</ProcessSegment>
</ProductionSchedule>
Modern MES platforms (Parsec, Plex, Wonderware) generate B2MML for downstream systems. The schema is standardized; the mapping to internal database schemas is vendor-specific.
Typical MES ↔ ERP Data Flow
- ERP → MES (Daily): Production forecast in B2MML. MES acknowledges and creates weekly schedules.
- MES → SCADA (Hourly): Updated recipe, material lot assignments, expected cycle times.
- SCADA → MES (Real-time): Downtime events, quality measurements, actual cycle times (often via OPC UA or MQTT bridges).
- MES → ERP (Hourly): Aggregated downtime, yield, material consumption, labor hours.
The mapping is not bidirectional on every field. ERP drives capacity planning; SCADA drives machine state; MES reconciles both.
ISA-99 and IEC 62443: Securing the Purdue Model
ISA-99, formally superseded by IEC 62443 (Cybersecurity for Industrial Automation and Control Systems), translates the five-level Purdue model into a security architecture. The core idea: each transition across a Purdue level boundary requires authentication, encryption, and audit.
The IEC 62443 Family
- 62443-1-1: Framework overview and vocabulary.
- 62443-2-1: Governance and risk assessment. How to inventory your ICS, classify criticality, assign responsibilities.
- 62443-3-3: System-level cybersecurity requirements. Foundational Requirements (FRs) 1–7 applied to industrial networks.
- 62443-4-1: Secure development practices. For control-system vendors building firmware and HMI software.
- 62443-4-2: Implementation guidelines for specific platforms (PLCs, HMIs, safety relays).
For practitioners implementing ISA-95, 62443-3-3 is the enforcement standard.
Security Levels and Foundational Requirements
IEC 62443 defines four Security Levels (SLs) per zone:
| SL | Maturity | Example Deployment | Threat Model |
|---|---|---|---|
| SL1 | Baseline, no security budget | Legacy equipment, closed networks | Insider threat (negligible) |
| SL2 | Basic controls | Standard Ethernet with ACLs, no encryption | Accidental misconfiguration |
| SL3 | Moderate defense depth | VPN + TLS, role-based access, logging | Opportunistic external attack |
| SL4 | Maximum defense + active response | Encrypted redundant networks, zero-trust, EDR | Sophisticated nation-state adversary |
Each Security Level prescribes seven Foundational Requirements:
- Identification & Authentication: Unique credentials (not shared), MFA for administrative access.
- Use Control: Role-based permissions. A sensor node cannot initiate communication with ERP.
- Data Confidentiality: Encryption at rest and in transit (AES-256, TLS 1.3).
- Data Integrity: Digital signatures, HMAC-SHA256, checksums. Tampered messages are rejected.
- Restricted Data Flow: Firewalls and routing policies enforce Purdue-level boundaries. Level 0 cannot directly query Level 3.
- Timely Response to Detected Events: Logging, alerting, and documented incident procedures.
- Resource Availability: Redundancy, DoS mitigation, graceful degradation under attack.
Zones and Conduits
ISA-99/62443 adds a spatial dimension to security: zones and conduits. A zone is a logical grouping of assets with uniform security policies. A conduit is a controlled pathway between zones.
Three-zone + IDMZ model (common):
┌─────────────────────────────┐
│ Level 3–4 (ERP/Planning) │ Zone A
│ │
└────────────────┬────────────┘
│
┌──────────┴──────────┐
│ DMZ / IDMZ │ Industrial DMZ
│ (Data historian, │ with gateway
│ cloud API proxy) │
└──────────┬──────────┘
│
┌───────────┴────────────┐
│ Level 1–2 (SCADA/MES) │ Zone B
│ │
└───────────┬────────────┘
│
┌────────┴────────┐
│ Level 0 (Field)│ Zone C
│ │
└─────────────────┘
Each boundary (Zone A ↔ DMZ, DMZ ↔ Zone B, Zone B ↔ Zone C) is a conduit with explicit ingress/egress rules. The rules are stateful: a command from MES to a PLC is allowed; unsolicited data from a PLC to MES is denied.
Common ISA-95 and ISA-99 Implementation Pitfalls
Pitfall 1: Treating ISA-95 as prescriptive technology.
ISA-95 defines data structures and roles, not TCP/IP stacks or database schemas. Teams that insist on “strict ISA-95 compliance” by mandating Siemens S7-1200s in Zone B or Oracle databases in Zone C miss the point. The standard is technology-agnostic. What matters is that the boundaries are clear and the data models are consistent.
Pitfall 2: ISA-99 compliance without threat modeling.
Many facilities follow the IEC 62443 checklist (enable TLS, set up SSH keys, write a security policy) and declare victory. But zones are only meaningful if you’ve actually inventoried assets, classified criticality, and assessed what happens if each zone is compromised. A pharmaceutical plant where Level 2 goes down is a regulatory incident; a food-processing plant where it goes down for 4 hours costs $50k in spoilage. The remediation strategy is not the same.
Pitfall 3: Over-partitioning the network.
Not every machine needs its own VLAN. Not every PLC needs a firewall rule. ISA-95 levels are logical separations; ISA-99 zones are security-driven groupings. A facility with 500 machines in a single production cell may reasonably treat all Level 0 equipment as one security zone (SL2) with a single ingress/egress firewall rule. Excessive micro-segmentation adds operational burden without proportional security gain.
Pitfall 4: Ignoring the data genealogy requirement.
ISA-95 Part 2 mandates that Material objects carry genealogy—which Equipment made this batch, what raw material went in, what quality tests were run. This is not optional for compliance (FDA, EMA, IATF). But it requires persistent IDs (not just “Batch #1”), careful handoffs between zones, and timestamping that survives clock resets. Many facilities retrofit this too late.
Pitfall 5: Assuming ISA-99 zones solve air-gapping.
A properly configured Zone B → Zone A conduit with encryption and role-based access is a form of air-gapping. But if the gateway runs 10-year-old Linux with unpatched OpenSSL, the zone boundary is theoretical. ISA-99 defines the structure; patch management and vulnerability assessment define the reality.
Modern Adaptations: Sparkplug B and the Unified Namespace
The Unified Namespace (UNS) flattens the traditional Purdue hierarchy by introducing a shared data-plane. Instead of cascading MES → ERP and SCADA → MES integrations, all devices publish to a single MQTT broker (or MQTT cluster) using the Sparkplug B specification. Consumers (MES, ERP, analytics) subscribe to the topics they need.
Sparkplug B and ISA-95 Levels
Sparkplug B is not a replacement for ISA-95; it’s an encoding of it. A Sparkplug B topic namespace might look like:
spBv1.0/facility-001/DDATA/zone-b/reactor-01/
temperature
pressure
state
batch_id
spBv1.0/facility-001/DDATA/zone-c/conveyor-02/
position
speed
error_code
This is still a Purdue model—Zone C (Field) publishes leaf metrics; Zone B (SCADA) publishes aggregates. The difference is transport: instead of discrete OPC UA connections or Modbus gateways, there’s a publish-subscribe fabric that decouples producer from consumer.
Pushing Level 2 Logic to the Edge
UNS enables edge computing. A gateway at the Zone B/C boundary can now run lightweight MES logic—recipe evaluation, sequence coordination, downtime alerting—without waiting for round-trip latency to a central MES server. This is not a violation of ISA-95 levels; it’s a relocation of Level 2 logic closer to execution. The security boundary remains: the edge controller still cannot initiate connections to Level 3.
Security Implications
UNS introduces a single point of failure: the MQTT broker. ISA-99 requires redundancy and fault tolerance. Best practice:
- Deploy MQTT clusters (e.g., EMQ X, Confluent Kafka) with replication factor ≥2.
- Implement broker authentication and topic-level ACLs.
- Use Sparkplug B’s state-change detection (NBIRTH/DBIRTH) to enforce clean session semantics and prevent ghost subscriptions.
- Encrypt all MQTT payloads (TLS 1.3) and sign metric values with HMAC-SHA256.
- Rate-limit publish frequency per device to prevent DoS from rogue sensors.
UNS does not eliminate the Purdue model; it reshapes it. Levels 0–2 converge into a real-time mesh; Levels 3–4 remain asynchronous consumers.
Trade-offs and When NOT to Use ISA-95/ISA-99
ISA-95 and ISA-99 impose overhead. They demand data models, governance, zone boundaries, and compliance audits. They are not universally the right choice.
When ISA-95/ISA-99 is essential:
– Regulated industries (pharma, food, automotive, utilities) with traceability and compliance requirements.
– Multi-site operations where standardization across facilities reduces integration cost and operational risk.
– Systems where a single failure (zone compromise, data loss, downtime) has million-dollar consequences.
When ISA-95 overhead is unjustified:
– Small greenfield IIoT deployments (10–50 sensors, single facility) with a modern cloud-native platform (MQTT + serverless analytics). A Sparkplug namespace is enough; formal ISA-99 zones may be premature.
– Closed-loop laboratory or test-rig equipment with no external connectivity. Physical isolation is simpler than cryptographic isolation.
– Legacy equipment (pre-2000) where retrofitting even basic EtherCAT or Modbus TCP is cost-prohibitive. Accept the manual data transfer; optimize incrementally.
When to migrate incrementally:
– Existing facility with ad-hoc integrations (FTP scripts, manual spreadsheets, OPC-DA connections over the internet).
– Year 1: Implement IEC 62443 Level 2 zones. Firewall off Level 0, place gateway in IDMZ.
– Year 2: Adopt Sparkplug B for Level 1 communications. Retire OPC-DA over internet.
– Year 3: Standardize on ISA-95 Part 2 data model. Implement MES-level genealogy tracking.
– Year 4: Achieve IEC 62443 Level 3 or SL3 maturity. Audit and document compliance.
Practical Recommendations
To implement ISA-95 and secure it with ISA-99, start with inventory and assessment:
-
Asset Inventory & Classification: Map every network-connected device (PLC, gateway, HMI, sensor), assign to Purdue level (0–4), and classify as critical or non-critical. Use a spreadsheet or CMDB.
-
Data Flow Audit: For each critical device, trace where its data goes. Reactor temperature → PLC → Gateway → MES → ERP → BI platform. Mark each hop as authorized or suspicious.
-
Zone Definition: Group devices by Purdue level and security tier. Common outcome: 3–5 zones (Field, Control, Supervision, Enterprise, DMZ).
-
Firewall & Gateway Rules: Implement stateful rules at zone boundaries. Document allow-list rules (not deny-list).
-
Encryption & Authentication: Deploy TLS for all zone-boundary communication. Implement mutual TLS (mTLS) between critical systems. Use managed certificate services (HashiCorp Vault, Kubernetes cert-manager).
-
Genealogy & Traceability: If regulatory, implement batch tracking. Assign unique identifiers to every material lot and batch run. Link to timestamp and equipment ID.
-
Monitoring & Incident Response: Log all zone-boundary crossings. Alert on anomalies (unexpected source IP, failed authentication, oversized payload). Write a runbook for containment (isolate zone, preserve logs, notify stakeholders).
Quick checklist:
– [ ] All Purdue levels identified and mapped to network zones
– [ ] All inter-zone communication encrypted (TLS 1.3 or AES-256)
– [ ] All administrative access requires MFA
– [ ] All data modifications logged with timestamp and user ID
– [ ] Incident-response runbook drafted and tested
– [ ] B2MML schema for MES-ERP integration agreed upon
– [ ] Backup and recovery plan tested for each zone
Frequently Asked Questions
What is the difference between ISA-95 and IEC 62443?
ISA-95 defines the architecture and data structures of industrial production systems across five levels. IEC 62443 defines the security policies and controls that protect those systems at each level. ISA-95 says “here is where data lives”; ISA-99/62443 says “here is how to defend it.” They are complementary, not competing.
Can we implement ISA-95 without IEC 62443?
Technically, yes—ISA-95 is purely architectural. Practically, no. Any facility with networked systems, regulatory requirements, or external data integration will face pressure to secure zone boundaries. IEC 62443 SL2 (basic controls) is a reasonable minimum for all industrial networks. SL3+ should be required wherever data drives financial or safety decisions.
Does UNS (Unified Namespace) replace Purdue model levels?
No. UNS provides a horizontal transport layer (MQTT) that decouples producers from consumers, but it does not eliminate the logical separation of concerns. A gateway running Sparkplug B is still operating at the boundary of two Purdue levels. ISA-95 levels describe responsibility and latency; UNS describes transport and topology. Both coexist.
How do we track material genealogy without a full MES?
If you cannot deploy a formal MES, use a lightweight batch-tracking database. Minimum fields: batch ID (UUID), timestamp, equipment ID, input material lot IDs, output quantity, quality result (pass/fail), operator ID. Capture at the PLC or gateway level via a simple REST API. This satisfies FDA 21 CFR Part 11 (audit trail) without the cost of a $500k MES license.
What is the minimum Security Level we should target?
For greenfield deployments, SL2 is acceptable (encryption, role-based access, basic logging). SL3 is advised for facilities with > 100 devices or > $10M annual revenue. SL4 is for critical infrastructure (power grids, water treatment, aviation). Do a threat model; don’t guess.
How do we migrate from OPC-DA (legacy) to Sparkplug B?
Parallel-run strategy: Deploy a new Sparkplug B MQTT broker. Place an OPC-DA → MQTT bridge at the IDMZ gateway. Bridge publishes legacy PLC data in Sparkplug B format. New consumers (MES v2, analytics) subscribe to MQTT. Old consumers (ERP, legacy HMI) read from bridge. Decommission OPC-DA connections over 12–18 months as legacy clients retire.
Further Reading
- Unified Namespace (UNS) and Digital Twin Architecture: Detailed Sparkplug B protocol walkthrough and UNS deployment patterns.
- IEC 62443: Industrial Control Systems Cybersecurity: Comprehensive IEC 62443 implementation guide with zone-design recipes.
- Profibus Protocol: Complete Technical Guide: Deep-dive on fieldbus real-time constraints relevant to Level 0–1 networks.
- MQTT vs CoAP vs AMQP: IoT Protocol Comparison: Latency and throughput analysis of Level 1–2 messaging protocols.
- EMQX Cluster on Kubernetes: Production Deployment: Hands-on guide for building fault-tolerant MQTT infrastructure for Sparkplug B.
References
- ANSI/ISA-95.00.01-2010: “Enterprise-Control System Integration, Part 1: Models and Terminology.” International Society of Automation. https://www.isa.org/intech/201012-isa95
- IEC 62443-3-3:2013: “Industrial Automation and Control Systems Security, Part 3-3: System Security Requirements and Security Levels.” International Electrotechnical Commission. https://webstore.iec.ch/publication/7032
- ISA-TR84.00.09:2020: “Use of Ethernet in Industrial Automation.” Technical Report by ISA. https://www.isa.org/
- NIST SP 800-82 Rev. 3: “Guide to Cybersecurity of Critical Infrastructure and Industrial Control Systems.” National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-82r3.pdf
- MESA International: “B2MML (Business to Manufacturing Markup Language) Schemas.” http://www.mesa.org/en/B2MML.html
- Braun, G., & Olsson, H. (2019). “Real-time Data Integration in Industrial IoT.” IEEE Industrial Electronics Magazine, 13(2), 42–52.
Last updated: April 22, 2026. Author: Riju (about).
