SINGAPORE, 21 AUG 2026 — The Cyber Security Agency of Singapore said on 22 July that it will rewrite the Cybersecurity Code of Practice governing the country's critical information infrastructure, and publish a separate code for cloud services in the second half of this year. The existing code was last updated in 2022.
The headline requirement is not a technical control, but a shift in responsibility. Boards and senior management will be held directly accountable for cyber resilience — not just for keeping attackers out, but for getting the service back online.
What the rewritten code requires
The announcement was made by Josephine Teo, Minister for Digital Development and Information and Minister-in-charge of Cybersecurity and Smart Nation Group, at the Operational Technology Cybersecurity Expert Panel Forum.
The rewritten code specifies six changes. Boards must now maintain an annually reviewed cyber resilience framework that covers risk tolerance, mitigation, transfer and recovery. Operators will need Cyber Trust Mark Level 5 certification and must deploy threat detection across all network segments. Oversight is also expanding beyond designated systems to include interconnected ones, and operators will be required to hold comprehensive cybersecurity exercise plans. Finally, the code strengthens network architecture management.
While each change is an incremental tightening, their combined effect is to shift where the burden of resilience sits.
The assumption that just broke
Teo's stated reasoning is worth following closely, because it is a causal argument rather than a generic warning about a changing threat landscape.
Operational technology security has rested for decades on a quiet assumption: that attacking a substation, a water treatment plant or a rail signalling system requires knowing how substations, water treatment plants and rail signalling systems work. That knowledge is scarce, slow to acquire and largely held by people who work in the sector. Complexity was doing the work of a control, without anyone having to fund it.
The minister named that assumption and said artificial intelligence has challenged it. Attackers without operational technology expertise can now target critical infrastructure in ways that were not previously available to them, and threat actors can exploit weak links within hours.
The claim is more specific than a general warning about AI. The minister is not asserting that models can write novel attacks against industrial systems, but that the knowledge barrier which kept most attackers out has fallen. If that is right, the population of plausible attackers against a Singapore power or water operator has expanded substantially without anything about the operator changing.
Three incidents were cited as evidence of the direction. Operation Cyber Guardian, attributed to the threat actor UNC3886, targeted all four of Singapore's major telecommunications operators. An attempted breach of a water utility in Monterrey in early 2026 used commercially available AI tools. An attack on Polish power infrastructure in late December 2025 reached more than thirty wind and solar farms alongside a combined heat and power plant.
Recovery is the word that changed
The most consequential change is the new emphasis on recovery. Operators are now expected to detect, respond and recover, and the board's framework must explicitly cover recovery alongside risk tolerance, mitigation and transfer.
Most cybersecurity obligation, in most jurisdictions, is written around prevention and detection. Those are the parts a security team can own. Recovery is different, because restoring a service after a destructive incident is an operational and financial question rather than a technical one: what is funded, what is rehearsed, how much degraded capacity is acceptable and for how long. Those decisions are made above the chief information security officer, or they are not made at all.
Requiring an annually reviewed board framework that names risk tolerance and risk transfer places the conversation where the money is. Risk transfer in particular is a board and finance matter, and its appearance in a cybersecurity code is a signal that the regulator does not accept insurance as a substitute for capability without the board having said so deliberately.
Whether this changes behaviour depends entirely on enforcement, and nothing published describes penalties.
A cloud code written with the cloud providers
The second instrument is new. As critical infrastructure operators migrate systems to public cloud, CSA will publish requirements governing the secure deployment, operation and management of those systems, with companion guides produced alongside Amazon Web Services, Google Cloud and Microsoft Azure.
The practical case for that collaboration is strong. Cloud security guidance written without the providers tends to be either vague enough to be useless or specific enough to be wrong within a release cycle, and the configuration detail that determines whether a deployment is actually safe lives inside each platform's own controls.
The tension is equally real and deserves naming rather than glossing. The three companies helping to author guidance for infrastructure hosted on their platforms have a commercial interest in that guidance being satisfiable on their platforms. A code that concluded some critical systems should not be in public cloud at all is not one the hyperscalers would help write.
This is not an accusation of bad faith. The companion guides will inevitably describe how to run critical infrastructure in the cloud safely, not whether particular systems belong there in the first place. That second question remains the operator's — and now, its board's.
This is the sequel to the May letter
In May, CSA wrote to critical infrastructure boards requiring cybersecurity reviews specifically addressing AI resilience, citing the compression of exploit development from months to hours. We reported that letter at the time.
The July announcement is what those reviews turn into. A letter asks operators to look at themselves; a code of practice states what they must be able to show. The progression from advisory correspondence in May to binding requirement in the same year is faster than this kind of instrument usually moves, and the gap between them is the window in which prepared operators had a head start.
Why regional operators should read this
Singapore designates and regulates critical information infrastructure more prescriptively than most of its neighbours, so the direct obligation is narrow. The transferable content is the reasoning.
Any operator across ASEAN whose operational technology security depends on the obscurity of its systems is relying on a control that Singapore's regulator has now publicly declared expired. That includes a great deal of regional utility, port and manufacturing infrastructure running equipment chosen for reliability rather than defensibility, where the honest security posture has always been that nobody sufficiently motivated has bothered to learn the protocol.
The second point concerns interconnected systems. Extending oversight beyond designated systems to what connects to them addresses the most common real-world failure: the corporate network, the vendor maintenance link or the building management system that was never in scope because it was not critical, and which turns out to be the route in.
What remains unconfirmed
Several points are unconfirmed. Publication dates for either code are vague ("later part of this year," "second half"). The announcement describes no penalties or enforcement mechanisms for board accountability, nor does it clarify if accountability means regulatory action against individuals or just a documentation obligation. The release also does not state how many infrastructure sectors are affected, what Cyber Trust Mark Level 5 will require of operators at lower tiers, or what transition period will apply. Finally, it is unclear whether the cloud code will bind operators, providers, or both.
What to watch for
The first test is whether the published code attaches consequences to the board framework or merely requires that it exist. A document reviewed annually and filed is not accountability.
The second is the transition period for Cyber Trust Mark Level 5. A demanding certification with a short runway forces spending; a long runway makes the requirement notional.
The third is whether the cloud companion guides address workload suitability at all, or restrict themselves to configuration. That will show how much of the code is regulation and how much is documentation.
View author profile → · Editorial policy
