Automation World first reported the announcement, which the International Society of Automation and its ISASecure subsidiary published on August 20. The NSA’s prior technical work shows why this matters: its April 2025 OT Assurance Partnership report found that existing ISA/IEC 62443-4-2 component requirements did not fully cover 13 controls in the NIST moderate-impact baseline it selected for National Security System smart controllers.
For Windows and enterprise administrators, the immediate lesson is less about a certificate to request this quarter and more about the security capabilities federal buyers are beginning to expect from industrial devices that increasingly connect to Windows engineering workstations, management networks, historians, remote-access systems, and identity infrastructure.
HCSA is a certification scheme under development, not a current product list
The announcement’s most important qualifier is also its easiest to miss. ISASecure says it is developing HCSA from its existing Component Security Assurance program; the NSA will use it as an approved certification mechanism only after the OT Assurance Partnership program office accepts the finished scheme.
That means no manufacturer can yet point to an HCSA certificate, and an HCSA certificate would not by itself put a product on the NSA’s Product Compliant List. The stated process is sequential: a vendor obtains certification, the certificate becomes evidence in the evaluation process, and the NSA then considers the product for the list. Procurement teams should not read the announcement as an immediate exclusion of uncertified products, nor should suppliers market existing ISA/IEC 62443 certification as proof of future HCSA eligibility.
ISA has not published an HCSA technical specification, a list of approved certification bodies, fees, a testing timetable, or a first cohort of products. It also has not said whether the scheme will initially cover only the “smart controllers” addressed in the NSA report or a wider collection of OT components. Those omissions are normal for a scheme at this stage, but they are material for manufacturers planning a federal sales cycle and for integrators deciding whether to make HCSA a contractual requirement now.
The defensible procurement position is therefore to track HCSA as an emerging assurance requirement, not treat it as a completed compliance program.
The added requirements are concrete device controls, not generic OT language
HCSA is intended to build on ISASecure’s established Component Security Assurance certification program, which evaluates products against ISA/IEC 62443 requirements. The new scheme will also incorporate six technical requirements developed through the NSA’s Operational Technology Assurance Partnership, or OTAP.
Those additions are much more operationally specific than the announcement suggests. The NSA report says a National Security System smart controller must meet 74 relevant ISA/IEC 62443-4-2 requirements across security levels 1 through 3, plus six additional requirements needed to meet the selected NIST moderate-moderate-moderate baseline.
The six additions focus on gaps that appear repeatedly in real OT deployments:
- Wireless-capable controllers must be capable of physically disabling wireless interfaces, and wireless must be disabled by default in operating-system or application settings.
- Controllers that can operate as wireless access points must disable SSID broadcast by default.
- A controller with a connected display must support a configurable pattern-hiding screen when a session is locked, while allowing necessary safety or operational information to remain visible.
- Controllers must be able to restrict unauthorized removable media, including devices such as USB storage, laptops, SD cards, and external drives.
- Controllers must protect confidentiality using cryptography for relevant data at rest and in transit.
- Controllers must use approved cryptographic security measures rather than merely offering an encryption feature.
This is a useful distinction. A device that advertises secure remote management, encrypted communications, or ISA/IEC 62443 alignment may still fail the future HCSA criteria if it cannot disable wireless hardware, control locally attached media, or apply cryptography in the manner expected for National Security Systems.
The NSA report explains that the agency identified 13 NIST control gaps after mapping the ISA/IEC 62443-4-2 requirements to its target baseline. The six new requirements consolidate coverage for those gaps, including wireless security, encryption, removable media, display protection, and port or I/O access. HCSA therefore appears designed to test a specific federal assurance overlay rather than create another broad marketing label for industrial cybersecurity.
Smart controllers are the first target because they bridge OT and enterprise IT
The NSA’s report defines a smart controller broadly enough to include programmable logic controllers, field devices, and related embedded components with processing, communications, and often edge-computing capabilities. These devices are no longer isolated control endpoints in many environments. They are configured from engineering laptops, monitored through central platforms, patched through vendor tools, and sometimes exposed to remote-support paths.
That convergence puts Windows administrators closer to the risk than a traditional separation between “IT” and “plant systems” implies. A Windows jump host used for PLC programming, an Active Directory account granted remote engineering access, a file share holding controller projects, or a USB device used for field updates can become part of the security boundary that HCSA is trying to strengthen at the component level.
The NSA’s technical report specifically calls out hard-coded credentials, insecure communications, removable-media exposure, and weaknesses associated with connected embedded systems. It also notes that administrative credentials must be protected wherever they reside and that firmware and software need regular testing and updating by an administrator or integrator. Certification can validate product capabilities, but it cannot turn poor operational practice into a secure deployment.
A controller capable of blocking unauthorized removable media remains vulnerable if the deployment team leaves every service port enabled. A product with cryptographic functions can still be misconfigured with weak protocols, unmanaged certificates, or unprotected engineering credentials. And a controller with wireless disabled by default can be re-exposed later by an installer who enables convenience features without a documented change process.
Federal buyers will gain a sharper supply-chain screen; operators still own deployment risk
The Product Compliant List is significant because it moves security assurance into purchasing decisions. Rather than asking each program office to interpret a vendor’s security claims, the NSA intends to use HCSA certification as an approved input to its assessment process for original-equipment manufacturer components.
For manufacturers, this creates a likely market-access incentive around verifiable security functions. For government program managers and system integrators, it could create a more repeatable method to distinguish between devices that claim conformance and devices assessed against the additional NSS requirements.
But it is still component assurance. The NSA’s own report makes clear that organizational security policy determines how extensively a component’s capabilities are used inside an OT system. HCSA will not evaluate whether a site has segmented its engineering network correctly, protected Windows administrative accounts, limited remote vendor access, monitored controller changes, or prepared recovery procedures for a compromised process environment.
Administrators responsible for OT-adjacent Windows infrastructure should use the emerging requirements as a practical review list now. Inventory wireless-enabled controllers, identify where engineering teams use removable media, document which jump servers and accounts can administer controllers, and verify how firmware packages and configuration backups are validated. Those are useful controls regardless of whether an organization buys into the future HCSA scheme.
The next milestone is acceptance of the scheme, not vendor certification claims
ISA and ISASecure have announced a partnership and a planned framework; the NSA’s 2025 technical report supplies the security rationale and the underlying requirements. What has not yet been published is the completed HCSA rulebook: its exact scope, test methods, certification-body roster, timelines, and the first products accepted for consideration on the NSA list.
Until those details arrive, federal contractors and OT vendors should avoid overstating readiness. Existing ISA/IEC 62443 certification may provide a foundation, but HCSA’s added controls point to a more demanding checklist for high-criticality smart controllers. The first meaningful proof of the program will be a public, accepted scheme followed by named products that have passed it—not the announcement that development has begun.