IEC 62443: A reader's reference

This page is a condensed companion to the IEC 62443 material in the book. It's written for readers who want the framework at hand without flipping between chapters, and for working security folks who want a quick map from Bitcoin to the standard they already know. Everything here is applied in depth in Part II of Defending Bitcoin. This page is the index.

What it is

ISA/IEC 62443 is a family of international standards for the cybersecurity of Industrial Automation and Control Systems, jointly developed by the International Society of Automation and the International Electrotechnical Commission. It covers everything from high-level concepts down to specific device requirements, and it's the framework engineers reach for when they're defending distributed, safety-critical, multi-party systems where availability dominates and a cyber failure can spill into the physical world.

Defending Bitcoin uses 62443 as its analytical lens because Bitcoin shares more DNA with industrial control systems than with typical IT. Availability is the first priority. Integrity is cryptographically enforced at every node. Confidentiality, in the form of privacy, is the property Bitcoin gives up by default and has to recover deliberately. That ordering is an OT ordering, not an IT ordering, and the framework that takes it seriously is 62443.

The framework was designed for environments with asset owners, system integrators, and product suppliers. Bitcoin has none of those things. There's no central operator, no governance committee, and no one to mandate controls across the network. Chapter 4 introduces 62443 in its native industrial setting. Chapter 5 adapts it to Bitcoin, where each participant is their own asset owner. Every threat chapter in Part II then maps back to the pieces of 62443 laid out below: the Foundational Requirements, the Security Levels, and the zone-and-conduit model for segmentation.

One caveat worth stating up front. 62443 assumes every user has a known identity. Bitcoin doesn't, and neither do most machine-to-machine systems. That gap is real, and the book works around it rather than pretending it isn't there.

The Purdue Model: Levels 0 through 5

The Purdue Enterprise Reference Architecture, published by Theodore J. Williams in 1989, is the reference model that 62443 implicitly assumes. It divides an industrial environment into levels, from the physical process at the bottom to the enterprise IT network at the top, with the expectation that each level is separated from the next by controlled boundaries rather than open connections.

Read from the top down, the levels are:

• Level 5, Enterprise Network. Corporate IT. Laptops, email, the systems that run the business rather than the plant.
• Level 4, Business Logistics. The IT side of the IT/OT boundary. Business systems that feed instructions down and pull reporting up.
• Level 3.5, Demilitarized Zone (DMZ). Added to the model after the fact because IT and OT eventually had to talk. All cross-boundary traffic is supposed to pass through here. If traffic flows straight through, the DMZ isn't doing its job.
• Level 3, Manufacturing Operations. Historians, site operations, the systems that collect process data and hand it upward.
• Level 2, Supervisory Control. SCADA and DCS systems. The operator's window on the process.
• Level 1, Basic Control. PLCs and RTUs executing the control logic.
• Level 0, Physical Process. The sensors and actuators that measure and change the real world.

Levels 4 and 5 are IT. Level 3 and below are OT. The gap between them is where 62443 does most of its work.

Chapter 5 applies the Purdue Model to a Bitcoin mining facility as the most direct Bitcoin-native example: hash computation sits at Level 0, ASICs and their controllers at Level 1, pool software at Level 2, operations centers at Level 3, a DMZ at Level 3.5 that many operators skip, and the exchange, custodial, and business systems at Level 4 and above. The book's broader point is that mining gives us a concrete place where OT architecture applies with minimal adaptation, and where skipping the DMZ is the same mistake industrial operators have been making for thirty years.

Security Levels: SL1, SL2, SL3, SL4

Each foundational requirement (FR1–FR7) has four target Security Levels. Defending Bitcoin uses SL1, SL2, and SL3 as the primary tiers; SL4 (defense against state-level adversaries) is acknowledged but rarely the practical target for individual holders.

• SL1, protection against casual or coincidental violation
• SL2, protection against intentional violation using simple means with low resources
• SL3, protection against intentional violation using sophisticated means with moderate resources
• SL4, protection against intentional violation using sophisticated means with extended resources

Security Levels are calibrated to the threat. SL1 stops the kind of mistakes a curious insider or untrained operator might make. SL2 stops a disgruntled employee or a low-skill opportunist. SL3 is aimed at organized criminals and hacktivists with time, money, and technical depth. SL4 is the nation-state tier, aimed at advanced persistent threats with extended resources and institutional patience.

Each 62443 control carries an SL rating, and higher-level controls generally build on lower-level ones. The book uses human authentication as the canonical example: a username and password is SL1, complexity rules and lockout push you to SL2, multi-factor authentication resistant to replay reaches SL3, and phishing-resistant hardware keys with resistance to sophisticated man-in-the-middle attacks get you to SL4.

Chapter 5 maps this progression directly onto Bitcoin custody. A phone wallet is SL1. A hardware wallet with offline keys is SL2. A hardware wallet with a memorized passphrase, or a 2-of-3 multisig with keys in multiple locations, reaches SL3. A 3-of-5 multisig with keys distributed across jurisdictions, optionally with a collaborative custody partner, is the SL4 answer for generational wealth or a public target. The point of the ladder isn't that everyone belongs at the top. It's that your controls should match the threat you actually expect, and the framework gives you a shared vocabulary for making that choice deliberately.

Foundational Requirements: FR1 through FR7

The seven top-level capabilities every IACS is expected to provide.

• FR1, Identification and Authentication Control. Know who or what is performing an action.
• FR2, Use Control. Authorize actions based on identity and policy.
• FR3, System Integrity. Prevent unauthorized modification of code or data.
• FR4, Data Confidentiality. Prevent unauthorized disclosure of information.
• FR5, Restricted Data Flow. Segment networks; control what crosses boundaries.
• FR6, Timely Response to Events. Detect and respond to incidents.
• FR7, Resource Availability. Ensure essential services remain available.

The FRs are the book's organizing spine. Every threat chapter in Part II is mapped back to one or more of them, and the Conclusion's Unified Control Table is structured the same way. A one-word shorthand for each helps: Authentication, Authorization, Integrity, Confidentiality, Segmentation, Response, Availability.

FR1 shows up any time you prove you're you. Exchange logins with MFA are the obvious case, but the private key itself is the deepest example. Possession of the key is authentication, and the network has no other notion of identity (Chapter 7).

FR2 is about what you're allowed to do once you're authenticated. In Bitcoin, use control is enforced in script: multisig thresholds, timelocks for inheritance, and relay policies that decide which transactions a node will forward (Chapters 7 and 10).

FR3 is where Bitcoin excels almost by default. Every transaction is signed, every block is hashed, and every node independently verifies the rules. The protocol is an integrity machine. FR3 is also the lens for developer risk, Core's release process, and the supply-chain attacks covered in Chapter 12.

FR4 covers both key secrecy (Chapter 7) and transaction privacy (Chapter 8). Bitcoin inverts the typical OT priority here, because the ledger is public by design and confidentiality has to be added deliberately through address rotation, CoinJoin, Silent Payments, and operational hygiene.

FR5 is segmentation: the boundary that keeps a compromise in one zone from reaching another. Mining facilities are the most literal application (Chapter 5). At the personal level, FR5 is the argument for separating your cold storage from your hot wallet and for not running a node on your daily-driver laptop.

FR6 is detection and response. In Bitcoin this means address-monitoring alerts, Lightning watchtowers (Chapter 7), and the personal incident response plan you hope you'll never need.

FR7 is why the rest of the book exists. Availability is what Bitcoin must preserve to remain money. Node redundancy, seed backups, geographic distribution, and protocol-level uptime all live here (Chapters 10, 13, and 14).

Zones and Conduits

Segmentation is the formal expression of FR5, and 62443 expresses it through zones and conduits. A zone is a grouping of assets that share common security requirements. A conduit is a defined, controlled communication path between zones. Threats are evaluated at the conduit boundary. Controls are designed at the zone level. The model forces the question of what actually needs to talk to what, and it makes the answer auditable.

The Purdue Model is itself a zone-and-conduit diagram. The IT layers (Levels 4 and 5) are one zone. The OT layers (Level 3 and below) are another. The DMZ at Level 3.5 is the conduit between them, and if an IT host can reach a PLC without passing through a defined conduit, the segmentation has failed. Chapter 4 uses NotPetya as the case study. The attack cascaded through flat enterprise networks because the conduits weren't there, or weren't enforced, and a single compromised tax-software update ended up shutting down ports from New Jersey to Mumbai.

The same logic applies to Bitcoin. A mining facility with no separation between office workstations and the controllers managing the ASICs is one phishing email away from a compromise of the physical process. Chapter 5 walks through that scenario directly. At the personal custody level, zone thinking is the reason cold storage lives on a dedicated device that never touches the internet, why the machine you use for signing is not the machine you use for browsing, and why a hardware wallet is effectively its own zone with a single narrow conduit (the signing interface) to the outside world.

Zones and conduits don't prevent attacks. They decide what an attack can reach once it lands. In a system where the money moves as fast as Bitcoin does, that decision is often the difference between a bad day and a permanent loss.