The Security of Critical Infrastructure Act 2018 puts duties on the responsible entities of critical infrastructure assets: register information, run a critical infrastructure risk management program, notify cyber incidents, and for some assets, plan incident response. It does not mention SBOMs. Suppliers feel it through what their customers must show.
What does the Act contain?
The Federal Register of Legislation lists the Act as administered by the Department of Home Affairs, with the version we reviewed dated 4 June 2026 in force. Its table of contents shows the structure that matters for suppliers.
- Part 2: Register of Critical Infrastructure Assets. The Secretary keeps a register. Entities have obligations to give information and notify certain events.
- Part 2A: Critical infrastructure risk management programs. A responsible entity must have a program, must comply with it, review it, update it, and submit an annual report. There are also provisions for directions to vary a program.
- Part 2AA: reporting obligations for certain assets not covered by a risk management program.
- Part 2B: Notification of cyber security incidents. It separates notification of critical cyber security incidents from other cyber security incidents.
- Part 2C: Enhanced cyber security obligations. These include statutory incident response planning obligations, where a responsible entity must have, comply with, review and update an incident response plan, and give a copy to the Secretary.
We reviewed the structure of the Act only. The detailed content of what a risk management program must address sits in the Act and in rules made under it, so read the current rules before you describe a specific requirement to a customer.
Who is a responsible entity?
The owners and operators of assets that the Act and its rules cover. Which assets, and which obligations apply to each, depends on the asset class and any determination by the Secretary. A software supplier is usually not a responsible entity. It is a supplier to one, and the Act does not regulate it directly.
How does it reach a supplier?
Through the program the customer must keep and follow. A program that covers risk to an asset has to deal with the things the asset depends on, and software and service providers are among them. The customer therefore needs to know what software runs the asset, who maintains it, and what happens when a vulnerability or incident appears in it.
A constructed example: a water utility runs a scheduling system from a vendor. A flaw is published in a library that the system embeds. The utility's program says it will assess supply chain hazards, and Part 2B means a significant cyber incident has a notification path. The utility asks the vendor three questions: is the component in our version, is it exploitable in our configuration, and when will a fix ship? A vendor with a current SBOM and a clear impact statement answers in a day. A vendor without them slows down the customer's own compliance.
What should a supplier prepare?
- An SBOM per release, with exact versions and a way to match it to what a customer actually deploys.
- A vulnerability impact process: affected, not affected, or under investigation, with dates and reasoning.
- Incident notification terms that give the customer enough time and detail to meet its own duties, with named contacts.
- Patch and support commitments, including how long you maintain old versions, because legacy assets are common in infrastructure.
- Remote access controls: who at your company can reach customer systems, how it is logged and revoked.
- Evidence you can share without leaking other customers' data.
What to do
- Read the Act's current text and rules for the asset classes of your customers.
- Ask your customers which of their assets are in scope and how they want supplier information delivered.
- Generate and keep an SBOM for every release you support.
- Write the impact statement template and test it on a past vulnerability.
- Review contracts for incident notification clauses and support periods.
- Avoid compliance claims you cannot back with documents.
Safeguard can generate SBOMs and scan dependencies, and its compliance automation helps collect evidence. It cannot make you or your customer compliant with the Act.
Quick check
Does the SOCI Act require suppliers to provide an SBOM?
Not in the parts of the Act we reviewed. The duties fall on responsible entities, and an SBOM is a practical way for a supplier to support them.
Is a software vendor a responsible entity?
Usually not. It supplies one. Check the Act and rules for the asset classes involved.
Sources
Last reviewed: 18 October 2026.
