What ISASecure ACSSA certification actually evaluates

If you operate a plant, a utility network, a pipeline or a building-automation estate and have been asked to show the control system is "62443 certified," the ISASecure program built for you is ACSSA, Automation and Control System Security Assurance. This article is the map.

The certificate in one sentence

An ACSSA certificate says that this asset owner's installed industrial automation and control system, bounded by its own asset inventory, equipment list, service providers, personnel and security program, is operated at maturity level 3 against IEC 62443-2-1; that its risk assessment conforms to IEC 62443-3-2; that the IEC 62443-3-3 capabilities each zone needs for its target security level are configured and in use; and that integration and maintenance services on it conform to the applicable IEC 62443-2-4 requirements.

Three things carry the weight: an installed system, not a product; level 3 everywhere, practised rather than merely documented; and a security level the asset owner brings in, not one the certificate hands out.

Two schemes, one evaluation method

ACSSA is two conformity-assessment schemes sharing one evaluation method and the same per-requirement criteria. Inspection bodies run the first under ISO/IEC 17020; certification bodies run the second under ISO/IEC 17065. An inspection report gives a result for each requirement and no overall pass or fail. A certificate, the subject of this series, is a single overall statement with a fixed validity, kept alive through surveillance and recertification. The document set is new: all first public versions are dated January to February 2026.

An installed system, owned by one asset owner

The object is an industrial automation and control system as the accountable asset owner has deployed it: hardware and software, the people who operate and maintain it, and the policies and procedures they follow, in operation or ready to go into operation. It is not a product, not a site as such, and not an organisation-wide management system. Only an asset owner can apply; system integrators, maintenance contractors and product suppliers take part as sources of evidence, never as applicants.

The asset owner draws the boundary with six change-controlled documents: the named asset-owner organisation, the hardware and software asset inventory, the equipment under control, the service providers, the personnel assigned to interact with the system, and the documented security program. Their versions fix what "the IACS" means at an agreed month and year.

Inside that boundary the IEC 62443-3-2 model applies: one or more systems under consideration, each typically one risk assessment's scope, divided into zones and conduits. Conduits containing devices are evaluated like zones; those without receive no separate results.

Four standards and two support items

IEC 62443-2-1 is the primary list, the asset owner's security-program requirements. IEC 62443-3-2 covers the risk assessment that partitions the system and sets each zone's target level; IEC 62443-3-3 the technical capabilities that must be configured and used in each zone; IEC 62443-2-4 the service providers, only for the tasks they perform on this system. ACSSA adds two policy-and-procedure-support items for the two IEC 62443-3-3 requirements with no governing IEC 62443-2-1 requirement.

The unit of work is the evaluation method; the ACSSA-311 workbook (version 1.3, February 2026) holds 422: one requirement item at one security level, with an activity for each maturity level at which it is evaluated. A security-program requirement whose associated capabilities span several levels gets one method per level; ISCI's example, USER 1.8, carries four.

Behind the 422 methods sit 349 requirement items: 87 from IEC 62443-2-1, the count ACSSA-303 states, plus the 2 support items, 123 from IEC 62443-2-4, 33 from IEC 62443-3-2 and 104 from IEC 62443-3-3. The 89 asset-owner requirements carry the verdicts: each receives one composite result folding the owner's own policies and practice with the results of its associated service-provider, risk-assessment and capability requirements. Ten result types exist; only "Not met" fails.

Two maturity levels, and certification needs level 3 everywhere

Each security-program requirement is judged at one of two maturity levels. At level 2 the policies and procedures exist in writing. At level 3 they are demonstrably carried out for this system: records exist, people can describe what they do, and the configuration matches. The definitions are IEC 62443-2-1's own; a system run at level 4 is evaluated as meeting level 3, and level 1 exists only in the inspection scheme.

Two rules catch first-time applicants. The evaluator determines the level; the applicant does not declare one. And certification requires level 3 on every requirement across all four parts: no partial certificate, no level 2 certificate. IEC 62443-3-3 capability requirements are evaluated at level 3 only: a capability configured and in use is practice, not paperwork.

Security levels are your input, not an award

Each zone and device-bearing conduit has a target security level, SL-T 1 to 4, set by the asset owner's IEC 62443-3-2 risk assessment. ACSSA uses it to decide which IEC 62443-3-3 capabilities must be present and used in that zone: those at or below the target, plus anything the owner's cybersecurity requirements specification demands. A capability above the target is recorded as not required at that level. One at or below the target that is not present, or not used across the whole zone, must be covered by a documented compensating security measure or a risk-based rationale, each approved by the asset owner and every affected stakeholder; otherwise the requirement is Not met.

ACSSA awards or computes no security level, the sharpest contrast with the product scheme SSA, which awards a capability level per zone.

Four phases, no testing

ACSSA-304 organises an evaluation into four phases: risk-assessment evaluation, maturity level 2 evaluation, maturity level 3 evaluation, and report preparation. Phases 1, 2 and 4 may be performed remotely. Phase 3 may not. Whether a control is really configured, and whether daily practice matches the written procedure, can only be judged in person; the same holds at the premises of each service provider evaluated.

Three kinds of evidence feed the evaluation: documents and artifacts, interviews with the people who run and maintain it, and inspection of systems and networks. The evaluator performs no testing and does not access devices: the asset owner's staff open configurations or exercise controls while the evaluator watches. As an ISASecure certification body, this is the method we work to.

At level 3 the evaluation samples zones and device-bearing conduits, and may sample systems under consideration where architectures are replicated. The sample must include the zone at the highest target level with the most technical capabilities; service-provider requirements are never sampled; and the certification body, not the asset owner, chooses the sample.

After the certificate: the lifecycle in one paragraph

ACSSA-300 §5 sets the cycle. A certificate is valid to the end of the 36th month after grant, while the asset owner stays in good standing. Surveillance audits fall in years one and two: a general part reviewing logged changes to the scope documents, service-provider tasks and personnel, the risk assessment and the security program, and progress on earlier findings; and a detailed part re-evaluating 30 asset-owner security-program requirements, 10 chosen by risk and 20 at random. A recertification audit every third year repeats every level 3 activity and, if passed, extends the certificate 36 months from the prior expiry. Nonconformities from the initial evaluation need a correction plan accepted within 30 days and closure within 90 days.

What ACSSA is not

• A product certificate. A controller, switch, HMI or software package on its own is a CSA object, or ICSA for IIoT devices and gateways. Certified products are not required; a product certificate shows that a capability exists, and the evaluator still checks configuration and use.
• A system-as-sold certificate. A control system one supplier offers and supports as a product is SSA's domain; ACSSA begins where SSA ends, with the installed, site-specific system.
• A service-provider certificate. Each provider is evaluated only for the tasks delegated on this system. A provider's own maturity level 3 IEC 62443-2-4 certificate, issued by a certification body accredited by an IAF MRA signatory, can satisfy the requirement it covers at ACSSA's level 2, never at level 3.
• A test. No vulnerability scan or penetration test is part of an ACSSA evaluation; the component series covers what a laboratory does test.

Where to go next

This article opens the ACSSA series; browse the rest from the ACSSA filter on the Insights index, or step across to the SSA and CSA series.