On the evening of August 3, 2018, a computer virus outbreak at TSMC hit a number of computer systems and fab tools in Taiwan. The company later explained that a misoperation during software installation on a new tool let the virus spread once the tool was connected to the company network, and it estimated the impact at about 3% of that quarter's revenue[1]; TSMC subsequently confirmed that the malware was a variant of the WannaCry ransomware[2]. The incident forced the semiconductor industry to face a simple fact: newly purchased equipment can itself be the way in. In 2022 SEMI published two equipment security standards, E187 and E188, with E187 developed by a task force co-led by representatives of TSMC and ITRI[3].

This guide is for three groups of readers: semiconductor equipment suppliers whose fab customers ask for SEMI E187 compliance, automation vendors and system integrators who are asked "does your product meet IEC 62443?", and factory IT/OT managers responsible for production-line security. A useful way to see how the two relate: IEC 62443 is a cross-industry series covering the whole industrial control environment, while SEMI E187 is the semiconductor industry's entry bar for tool computers.

Why OT security cannot simply copy IT practice

Operational technology (OT) is the set of systems that directly control physical processes, such as tool computers, PLCs, SCADA and DCS. NIST's OT security guide, SP 800-82 Rev. 3, sets out several key differences between OT and IT[4]:

  • Different priorities: IT security programs typically focus on confidentiality, integrity and availability, in that order; OT puts safety first, followed by availability, integrity and confidentiality[4].
  • No casual shutdowns or reboots: many processes run continuously, unexpected outages are unacceptable, and outages often have to be scheduled days or weeks in advance; the reboot that IT relies on is usually not acceptable in OT[4].
  • Patches have to wait: OT software updates must be thoroughly tested by both the vendor and the user and fitted into planned outages, sometimes followed by revalidation; many OT systems still run older operating systems that the vendor no longer patches[4].
  • Long equipment life: IT components last on the order of three to five years, OT often 10 to 15 years or longer, and an OT system as a whole can stay in service for more than 20 years[4].
  • Vendor lock-in: some OT licensing or service agreements do not allow third-party security software, and installing it without the vendor's approval can cost you vendor support[4].

The IEC likewise notes that the 62443 series exists because IT security measures are not always appropriate for industrial automation and control systems (IACS): the two differ in performance and availability requirements and in equipment lifetime, and an attack on OT can harm the environment or even threaten lives rather than cause only financial loss[5]. OT security therefore leans heavily on compensating controls. Where PLCs or DCS cannot run anti-malware, a firewall with deep packet inspection can stand in; where components on unsupported operating systems cannot be patched, an intrusion prevention system or a bump-in-the-wire security device in front of them can block attacks on known vulnerabilities[4].

IEC 62443: one series, four roles

IEC 62443 (also written ISA/IEC 62443) is the international standard series for the security of industrial automation and control systems. It is developed jointly by the ISA99 committee and IEC TC65/WG10, and the technical content is identical whether you buy it from ISA or IEC[6]; the IEC classifies it as a "horizontal standard" that applies across industries[5]. The ISA Global Cybersecurity Alliance (ISAGCA) quick start guide sorts the documents into four groups: Part 1 covers terminology, concepts and models; Part 2 covers policies and procedures, such as 2-1 for the asset owner's security program, 2-3 for patch management and 2-4 for service provider requirements; Part 3 covers the system level, including 3-2 security risk assessment for system design and 3-3 system security requirements and security levels; Part 4 covers the component level, including 4-1 for the product security development lifecycle (SDL) and 4-2 for technical security requirements for components[6].

Who reads which parts

62443 defines four principal roles, each mapped to different parts[6]:

  • Asset owner (the factory): ultimately accountable for the IACS. It sets up a security program under 2-1, partitions zones and conduits and performs risk assessment under 3-2, documents requirements in a cybersecurity requirements specification, and procures products and services that meet them.
  • Integration service provider (the system integrator): designs and implements automation solutions that meet the customer's security requirements and applies patches during integration; mainly 2-4, 3-2 and 3-3.
  • Maintenance service provider: delivers maintenance services that meet the asset owner's security policies; mainly 2-4 and 2-3.
  • Product supplier (equipment, controller and software vendors): establishes and sustains an SDL under 4-1, delivers products whose capabilities meet a security level under 3-3 (systems) or 4-2 (components), and supports them across the product lifecycle; components under 4-2 include embedded devices, host devices, network devices and software applications.

The guide stresses that although the asset owner is ultimately accountable, it depends on product suppliers and service providers, so it must carry security requirements through the whole supply chain; the IACS security program also has to be coordinated with the organization's overall information security management system (ISMS)[6]. Companies that already run ISO 27001 can add the OT-specific requirements on top of that framework.

Zones and conduits

The core of 62443 network architecture is the zone and the conduit. A zone groups logical or physical assets by risk or by criteria such as asset criticality, operational function, physical or logical location, required access or responsible organization; a conduit is a logical grouping of communication channels that share common security requirements and connect two or more zones[6]. Part 3-2 requires or recommends partitioning the following separately: business and control system assets, safety-related assets, temporarily connected devices, wireless devices, and devices connected via external networks[6]. Once partitioned, each zone can carry its own security requirements, and a successful attack can be contained to a single zone[6].

Security levels SL 1–4

62443-3-3 distinguishes four security levels by the attacker's means, resources, skills and motivation[6]:

  • SL 1: protection against casual or coincidental violation.
  • SL 2: protection against intentional violation using simple means, low resources, generic skills and low motivation.
  • SL 3: protection against intentional violation using sophisticated means, moderate resources, IACS-specific skills and moderate motivation.
  • SL 4: protection against intentional violation using sophisticated means, extended resources, IACS-specific skills and high motivation.

In practice, keep three kinds of level apart: the target level (SL-T) set for each zone and conduit after risk assessment, the capability level (SL-C) a product can provide when properly integrated and configured, and the achieved level (SL-A) actually measured once the system is in operation[6]. A product's SL-C is what you compare with the SL-T when buying, but the factory's eventual SL-A also depends on integration quality and day-to-day operations.

4-1: the supplier's secure development process

Part 4-2 lists the technical capabilities a component should have at each security level; 4-1 requires the supplier to run a secure development process made up of eight practices: security management, specification of security requirements, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management, and security guidelines[7]. Several requirements map directly onto what factories expect: security requirements for externally provided components (SM-9), receiving, assessing, addressing and disclosing security-related issues (DM-1 to DM-5), documentation of dependent component or operating system security updates (SUM-3), timely delivery of security patches (SUM-5), and security hardening guidelines (SG-3)[7].

Certification: ISASecure and IECEE

62443 is a standard; to show customers you conform, you can seek third-party certification. Two schemes are commonly used:

  • ISASecure: SDLA certifies the development process against 4-1, CSA certifies components against 4-2 (with ICSA for IIoT components), SSA certifies control systems against 3-3, and ACSSA is based on 2-1, 2-4, 3-2 and 3-3; assessments are carried out by certification bodies accredited to ISO/IEC 17065[8].
  • IECEE: the IEC's conformity assessment system offers two evaluations: whether an applicant can provide 62443-compliant security capabilities, and whether those capabilities have actually been applied to a specific product, automation solution or IACS; successful applicants receive the industrial cyber security capability certificate of conformity[5].

Keep in mind that a certificate only shows that a product or process is capable of a given security level; whether a factory is actually secure still depends on zoning, configuration and daily operations.

SEMI E187 and E188: the entry bar for semiconductor equipment

SEMI E187 (Specification for Cybersecurity of Fab Equipment) sets a cybersecurity baseline for fab equipment. It is intended to be applied by entities that provide equipment or services to semiconductor fabs, such as equipment suppliers and system integrators, and covers the design, operation and maintenance of semiconductor production equipment and automated material handling systems (AMHS)[9]. It sets fundamental requirements in four areas: operating system support, network security, endpoint protection, and security monitoring[9]. Read the scope carefully: E187 applies only to the computing devices of fab equipment running Windows or Linux, not to PLCs, SCADA or devices connected to them via sensor-actuator networks[9]; embedded devices such as PLCs are among the component types covered by IEC 62443-4-2[6]. The current version is E187-0122, first published in January 2022[9][10].

SEMI E188 (Specification for Malware Free Equipment Integration), published alongside E187, focuses on protecting against malware during initial integration, field service repairs, patching and maintenance, and sets requirements for the equipment and computing devices that suppliers bring onto the factory network[3]. It requires suppliers to scan equipment, and devices used for maintenance and support, for malware before shipment; to use trusted external sources such as NIST's SCAP and the NVD's CVSS to harden systems and to identify and report vulnerabilities; and to provide configuration documentation so equipment does not introduce insecure network configurations into the factory[3]. For how to read CVSS scores, see reading vulnerability IDs and scores.

A revision in progress: three security levels

A SEMI Taiwan task force is working on a major revision of E187, aimed partly at aligning it with IEC 62443, that introduces three cumulative security levels: SL1 is the baseline for all compliant equipment, including vendor-supported operating systems, pre-shipment vulnerability and malware scans, encrypted network communications and basic access control; SL2 adds requirements for equipment with higher availability or integrity expectations, particularly where vendors provide remote support over public networks; SL3 targets high-risk or safety-critical environments and emphasizes long-term upgrade planning, traceability and complete technical documentation[10]. In August 2026 SEMI said the task force aimed to move the revision to ballot within the year[10], so the revision is not yet final; certification and procurement should still follow the current version.

Taiwan's E187 certification scheme

The Administration for Digital Industries of Taiwan's Ministry of Digital Affairs and SEMI jointly own the "SEMI E187 Cybersecurity Specification for Fab Equipment Certification Scheme", version 1.0 of which was published on March 23, 2026. The Taiwan Accreditation Foundation (TAF) is the accreditation body; test laboratories must be accredited to ISO/IEC 17025 and certification bodies to ISO/IEC 17065; certificates of conformity are valid for three years with post-market surveillance at least once in that period; and if a change to certified equipment affects its security functions, the certification body assesses the impact and may require supplementary testing[11]. In September 2026 the ministry and SEMI unveiled the E187 certification mark; by then the Institute for Information Industry (III) and ITRI had obtained TAF accreditation as the first test laboratories, certification bodies were still going through accreditation, and the first marks were expected by the end of the year[12].

A practical path for equipment suppliers and factories

Equipment suppliers

  • OS support plan and component inventory: list each model's operating system version, the vendor's end-of-support date and the upgrade path, and maintain a software bill of materials (SBOM) for every shipped release so you can quickly tell a customer whether a given vulnerability affects them. For how to use SBOMs, see supply chain attacks.
  • Hardening baseline and configuration documents: disable unneeded services and ports, remove default accounts and passwords, and give customers written documentation of network settings, required ports and recommended protections; this covers both E188's configuration documentation requirement and 4-1's security hardening guidelines[3][7].
  • Pre-shipment scanning: scan equipment and maintenance devices for malware before shipment[3], and keep the records for customer review.
  • Vulnerability handling and updates: set up a vulnerability reporting contact, assess impact, and ship tested patches with documentation, in line with 4-1's management of security-related issues and security update management[7]. For prioritizing fixes, see patch prioritization.
  • Remote support design: if remote maintenance is needed, keep it off by default, let the customer control when it is enabled, and support multi-factor authentication and full session logging.

Factories

  • Asset inventory: list every tool computer (OS version, whether still supported), PLC, industrial switch and remote connection path. Without the list, there is nothing to zone.
  • Segment by zones and conduits: at minimum separate the office network from the production network, then zone by tool type and criticality, keeping temporarily connected devices, wireless devices and external connections in their own zones[6], and allow only the traffic each conduit needs. In the 2018 incident, the virus spread as soon as a new tool was connected to the company network[1]; for how ransomware moves laterally inside a network, see the ransomware attack chain.
  • Control remote maintenance: NIST recommends a defined process for requesting and enabling remote access, granting it only when justified and limited to what is needed, considering multi-factor authentication, removing access when it is no longer required, and monitoring remote activity[4]. For hardening the VPN and remote access devices themselves, see the edge device hardening checklist.
  • Control USB drives and visiting laptops: scan laptops, USB storage and other portable devices for malicious code before they connect to OT devices or networks, and do not permit unauthorized removable media on any OT node[4].
  • Write requirements into procurement: specify E187 conformance or certification, pre-shipment scan records, OS support duration and vulnerability notification obligations in purchase specifications for new tools; for control systems and components, require the 62443 capabilities that match the target security level of the zone they will sit in[6].
  • Use compensating controls for legacy tools: where old tools cannot be patched or run anti-malware, add segmentation, intrusion prevention or bump-in-the-wire devices, keep a register and review it regularly[4].

Action checklist

  • Suppliers: inventory each model's OS version and end-of-support date, turn it into a support and upgrade plan, and build an SBOM for each shipped release.
  • Suppliers: define a hardening baseline and network configuration documents, and set up malware scanning before shipment and before site maintenance visits.
  • Suppliers: set up a vulnerability reporting contact and a patch release process, then evaluate E187 certification or 62443-4-1/4-2 certification.
  • Factories: complete the OT asset inventory, draw the zone and conduit diagram, and separate the office network from the production network first.
  • Factories: put vendor remote maintenance under a request, time-limited enablement, MFA and session logging process.
  • Factories: enforce scanning and authorization for USB drives and visiting laptops.
  • Factories: write E187, 62443 target security levels and vulnerability notification requirements into purchase specifications for new tools and control systems.
  • If you need outside help with a gap analysis, see our security health check; follow equipment and ICS cases in advisories.