Up to issuance, an ICSA evaluation has the same shape as a CSA evaluation: development artifacts, a functional security assessment and vulnerability identification testing, with an SDLA certificate as the prerequisite. Then the two schemes part company. An ICSA certificate holder is audited periodically on how it maintains the security of the certified product, and the certificate can be suspended, restored or withdrawn on the strength of that audit. CSA has no surveillance element.
This article explains that audit, the Security Maintenance Audit or SMA, for the supplier that holds the certificate and the asset owner who relies on it.
A Type 5 scheme: certify, then keep checking
ISO/IEC 17067 classifies product-certification schemes by what happens after the certificate is granted. ICSA is a Type 5 scheme: the product is evaluated and certified, and the certificate is then kept under periodic surveillance. In ICSA that surveillance is the SMA, an evaluation element in its own right. Where the CSA and ICSA comparison counts three assessment streams plus an SDLA prerequisite, ICSA defines five elements: the SDLA prerequisite check, SDA-IC, FSA-IC, VIT-IC and the SMA. The first four produce the certificate; the fifth keeps it.
What the audit examines
The SMA does not re-evaluate the product. It examines four requirements from IEC 62443-4-1, the secure development lifecycle standard behind the supplier's SDLA certificate, drawn from its defect-management and update-management practices, as they were applied to the certified product over the period under audit.
| Requirement | What it covers, in plain terms |
|---|---|
| DM-1, DM-2 | A working path by which reports of security issues in the product reach the supplier, whatever their source, and the sorting of those reports into applicable and not |
| DM-4 | Deciding what to do about each issue that arrives, and following through on that decision |
| SUM-5 | Getting the resulting security updates out to users without undue delay |
Those requirements are examined through four audit topics:
- Notifications received. Whether reports of security issues reached the supplier from each major source and were correctly classified as applying to the product.
- User-reported issues. Those raised by the product's users, and how the supplier decided to deal with each.
- Severe issues. Those at or above the tier's severity band, high for Core and medium for Advanced, that were not fixed, and whether each has a reasonable documented explanation.
- Timely delivery of updates. Whether the security updates released in the period met the supplier's own policy for timely delivery.
An audit passes only when all four are met. Together they ask one question four ways: did the defect-handling and update process run for this product since the last look? A supplier whose process ran as designed answers from its own records; one that let it lapse has nothing to show.
How results are recorded: the addenda
The SMA produces no separate report; its results are appended as numbered addenda to the ICSA-303 assessment report from the initial evaluation. Every ICSA report carries an Addendum A from the outset, holding either the scheduled date of the first SMA or the record of a passed historical SMA, and each later audit adds its own addendum.
The assessment report becomes a living record of the product's maintenance history, and the certificate is amended at each audit to list the update versions currently supported, so the issue a supplier holds reflects the last audit rather than the original decision.
The historical audit option
One of the three first-audit options in ICSA-301 is a historical SMA: run alongside the initial evaluation, it applies the same practices and topics to the year before certification and to the product's earlier versions, certified or not. It is open only where those versions have been on the market for a year or more, and its result does not affect the initial certification. Its record fills Addendum A in place of a scheduled first-audit date, and the next audit then falls in the window described below.
When the audits fall
The scheduling rules are set out in ICSA-301, and there is no fixed interval. The supplier elects the first SMA from three options:
- A historical SMA covering the year before certification, run alongside the initial evaluation.
- An SMA covering the year after certification.
- An SMA timed to the next SDLA recertification, permitted when that falls 9 to 18 months after the ICSA certificate is issued.
After the first SMA, each later one falls at the supplier's SDLA recertification; after a historical SMA, the supplier instead picks a date between nine months and two years after initial certification, which may coincide with SDLA recertification.
Where more than three of a supplier's ICSA-certified products fall due at one SDLA recertification, later audits may be sampled in sets of three for up to three rounds: a clean set clears every product due; findings in the first set bring a supplier self-audit and a second set; findings again bring a third; and a nonconformity in the third set means suspension with no grace period and individual audits thereafter.
What happens when the audit finds problems
Each finding behind a failed SMA is a nonconformity, and under ICSA-301 the supplier and certification body agree a grace period, normally 30 to 90 days from its report, for submitting remediation evidence. At Perseus, a certification committee independent of the audit team decides the certificate's status, as ISO/IEC 17065 requires.
Suspension is a defined state with a defined exit. A nonconformity still open when the grace period ends suspends the certificate, and the supplier stops using the certification symbol. The certificate is restored once every open nonconformity has been closed within a year of being reported; one that stays open beyond that year brings withdrawal. Withdrawal also follows, within 90 days, where a vulnerability breaks a certified requirement or exceeds the product's agreed risk threshold and the supplier concludes it cannot be fixed with an update, with timing coordinated so users can be informed first. The scheme owner, ISCI, is notified at each status change.
Underneath this is one rule: an ICSA certificate has no fixed validity period. It stays valid for the certified version and its updates for as long as the supplier holds SDLA certification whose scope includes the product, the product remains in support and the supplier stays in good standing under the SMA. Let the SDLA certificate lapse and a one-year grace period runs before withdrawal; end the product's support and the certificate is withdrawn on the supplier's notification. A product stays certified not because it once passed an evaluation but because its supplier keeps demonstrating that the maintenance practices are running.
Product changes between audits
Changes to the certified product must be notified to the certification body, which decides whether the change needs no reassessment, additional evaluation or a new application; ICSA-301 sets the conditions under which certification carries across the product's updates.
What this means for suppliers
Keep the SDLA certificate current, with the product in its scope. It is the ICSA prerequisite, on the default path later audits fall at its recertification, and it conditions the certificate's validity; let it lapse and the ICSA certificate follows a year later.
Run DM-1, DM-2, DM-4 and SUM-5 as living processes, not certification-day artifacts. The audit reads what happened in the period, and an intake path nobody monitors or a disposition process that exists only on paper shows up as soon as the four topics are worked through.
Log as you go. Every notification received, every user-reported issue, every severity decision and every update delivery date, recorded at the time. Done that way, the SMA is a readout of records you already keep; done retrospectively, it is a reconstruction, and reconstructions are where findings come from.
What this means for asset owners
If you specify or buy ICSA-certified IIoT devices and gateways, the SMA is the part of the scheme that speaks to what you care about: not whether the product was secure on evaluation day, but whether it is being kept secure.
Ask for the current issue of the certificate, amended after each audit with the supported update versions, and for the report's addenda, which record every audit from Addendum A on. Ask whether the certificate is in good standing; a suspended one has at most a year from the finding's report to be restored. And check the supplier's SDLA certificate, since the certificate's validity rests on it and, on the default path, so does the audit schedule.
Where to go next
The CSA and ICSA comparison sets the SMA among the other differences between the two schemes; the CSA hub article covers the three assessment streams the two schemes share. The rest of this series is on the ICSA filter of the Insights index.
Frequently asked questions
No. It examines how four IEC 62443-4-1 requirements, receiving and sorting notifications of security issues, addressing them and delivering security updates in a timely way, were applied to the certified product over the period under audit. Changes to the product itself follow a separate path: the supplier notifies the certification body, which decides whether the change needs no reassessment, additional evaluation or a new application.