What file ingress looks like under CCoP 2.0

Every control set in the region asks for defence in depth, and Singapore's Cybersecurity Code of Practice for critical information infrastructure is no exception. It is one of those phrases that survives review meetings because nobody can be against it.

It is also, read literally, a claim about the kinds of control in a chain rather than the number of them. That distinction does almost no work in most of security, where layers genuinely differ: a firewall, an identity control and an endpoint agent are not variations on one idea. It does a great deal of work on file ingress, which is the one path where organisations routinely stack three or four controls that all answer the same question by the same method.

Who is in scope, and what changed

The Cybersecurity Act 2018 gives the Cyber Security Agency of Singapore the power to designate critical information infrastructure across eleven sectors: energy, info-communications, water, healthcare, banking and finance, security and emergency services, aviation, land transport, maritime, government and media. Designation is what converts the Code of Practice from guidance into a statutory obligation.

The Cybersecurity (Amendment) Act 2024 widened the perimeter considerably. From 31 October 2025, a new Part 3A reaches providers of essential services who do not own the infrastructure they depend on, together with cloud service providers and data centre operators. If your organisation concluded some years ago that the regime belonged to somebody else because you rent rather than own, that conclusion is worth re-checking.

CSA announced on 22 July 2026 that the Code will be updated again, to address advanced persistent threats and AI-enabled attacks, with a separate Code for Cloud Services on the same timetable. The announcement also referenced Cyber Trust Mark Level 5 certification in connection with the updated Code, which is the signal worth watching: a voluntary mark being named alongside a binding instrument tends to become a procurement filter for everyone selling into the sector, designated or not.

Where files actually enter

"File ingress" sounds like one thing. In a CII environment it is usually seven, and they are rarely owned by the same team.

1. Email attachments, which everybody has thought about, and which is the only path most control diagrams show.
2. Supplier and customer portals: upload forms, claims submissions, tender responses, onboarding documents. Frequently built by an application team, protected by whatever the application framework offered on the day.
3. Managed file transfer and scheduled exchanges with counterparties, where the control was designed around availability and reconciliation rather than content.
4. OT vendor material: firmware images, configuration files, PLC project files, commissioning documents. This path carries the highest consequence and the least inspection, because the formats are proprietary and the maintenance window is short.
5. Removable media at the IT and OT boundary, which formal policy usually prohibits and practice usually accommodates, because a vendor engineer has arrived with a laptop and a deadline.
6. Cloud storage and collaboration surfaces shared with third parties, where the file arrives without traversing anything an operator would recognise as a boundary.
7. Backup and restore paths, which reintroduce files that were admitted at some earlier point, under whatever control existed then.

Write those seven down against your own environment before arguing about engines. The exercise tends to resolve more risk than any product comparison, because the common finding is not that a control is weak. It is that three of the seven paths were never in scope for any control at all.

Why stacking similar controls is not depth

Take a path that is defended, and look at what defends it.

A typical inbound chain runs a gateway engine, then a second engine with a different vendor's signatures, then perhaps a sandbox. Three products, three invoices, three dashboards. Ask what question each one is answering and the answer is identical: is this file malicious? Ask how each one decides and the methods rhyme: pattern matching against known-bad, heuristics over structure, and behaviour observed in an environment the file may or may not choose to reveal itself in.

Where two controls share a method, they share the method's blind spot. Signature-based detection lags novel samples by however long it takes the sample to be collected, analysed and distributed, and adding a second signature set narrows that window without closing it. A sandbox is only as good as it has been designed: a file that checks for the sandbox, or that waits, or that needs a click the sandbox will not perform, behaves perfectly. Running it twice produces the same good behaviour twice.

Three controls sampling the same question is a consistency test. It tells you your engines agree. It does not tell you the file is safe, and under a Code that asks for depth it is one layer, reported as three.

Depth, in the sense the phrase claims, requires at least one control in the chain that reaches its verdict by a different route entirely. That is a category, not a product, and there are several: allowlisting by file type and source so that unexpected formats never reach a parser at all; a protocol break that forces content to be re-created rather than forwarded; deterministic rebuild of a document to its format specification, which produces the same outcome on a file nobody has seen before as on one everybody has; isolation of the rendering step so that parsing happens somewhere that does not matter.

Each has real costs, and it is worth naming them rather than pretending otherwise. Allowlisting generates exceptions, and exceptions accumulate until the list is decorative. Protocol breaks add latency that OT maintenance windows may not tolerate. Rebuilding changes files, which matters where a counterparty expects a byte-identical document or a signature to survive. Isolation moves the risk rather than removing it. A control set chosen on an honest reading of those costs will look different in a hospital and in a port.

The reading that survives an assessment

The CCoP requires continuous monitoring, behavioural anomaly detection across both IT and OT, and retention sufficient to support investigation and audit verification on demand. Those obligations are about seeing and proving. The depth argument above is about deciding, and the two meet at a practical point: an assessor asking how a given path is defended will accept a chain of similar engines, but the description of that chain writes itself into one sentence, and the sentence is that everything on this path is decided the same way.

For financial institutions the MAS Technology Risk Management Guidelines set the parallel expectation in different words: untrusted files arriving by email, upload portal or third-party exchange are handled at the boundary rather than admitted on a verdict and reviewed afterwards.

Neither instrument names a technology, and neither should. What both are asking, in the end, is whether the operator can describe the path a file takes and the reasoning applied to it at each step. Seven paths, a method per step, and an honest note against the steps where the method repeats: that document is an afternoon's work, and it is the one that makes the rest of the conversation sensible.

Fuller control mappings and instrument detail are on our Singapore compliance page.