In the AI Era, Certified Security Alone Is No Longer Enough

When did your board, foundation board or executive team last discuss cybersecurity, and specifically that artificial intelligence raises the likelihood of a cyberattack more than it raises the potential damage per incident? Anyone who carries responsibility on a board or executive team knows the uncomfortable position behind that. You are liable for risks you often cannot assess in detail.

The lever AI pulls sits less in the damage per incident than in the likelihood of an incident happening at all.

At its core, this is about judgement competence. It is not about mastering every technical detail yourself. It is about being able to judge whether the answers you receive hold up. That is not optional, because the duty of care, and the business judgment rule as recognised in Swiss case law, expect decisions made on an adequate information basis. Whether information is adequate, though, can only be judged with exactly this competence.

From my perspective, this seemed defensible for a long time in cybersecurity. Risk assessment lived off the assumption that known and unknown gaps exist, and off the hope that exploiting them would be costly, effortful and tied to rare specialist knowledge. That kept the probability low enough on the risk map to push it aside. That very assumption is now shifting dramatically, driven by the broad availability of AI. Against this backdrop, the concern about the offensive capabilities of the newest generation of AI models is not unfounded.

This stance went uncorrected for a long time, not even after Edward Snowden’s revelations in 2013. I gave several talks and presentations on this topic at the time, in which I could show that surveillance was not targeted at a few suspects. Collection happened at scale, gathering whatever could be gathered, up to direct access to the data of major internet companies and the interception of traffic between their data centres. The impact of what I said has remained limited to this day.

This is where, in my view, the misconception lies that still shapes today’s discussions. Any system can be a target, and in different roles. A single computer or an SME environment need not be the actual prize. It can serve as one of thousands of hijacked systems used to launch an attack on another target. In this context, I repeat my own view: it is not a question of whether you will be attacked. It is a question of when, because most attacks serve a direct or indirect economic interest.

The variable that is shifting

The reason does not lie in a single new attack. It lies in a changed threat landscape. The familiar model no longer fits, because anyone who reacts only once an incident is beyond doubt reacts too late, since the attacker has already gained position and built persistence by then. Security is therefore less a state you reach once and get certified, and more an ongoing management of probabilities that rise and fall.

As the construction of working exploits from known flaws becomes scalable, it is not primarily the damage per incident that rises. It is, above all, the probability that an incident happens at all. This is exactly the point that executive teams and boards need to reassess. The finding matches what the World Economic Forum’s Global Cybersecurity Outlook 2026 names as one of the biggest concerns tied to generative AI: the advancement of adversarial capabilities, from phishing through malware development to deepfakes. The specialist literature, too, describes attackers using generative AI as more sophisticated. Above all, though, they become scalable and adaptive.

This shift hits risk assessment at its most sensitive point. A company manages risk through the product of probability and severity. Many programmes are built to limit severity, through emergency plans, insurance, recovery. If probability now moves upward, the entire matrix shifts, and part of the existing prioritisation is called into question.

Of course, the other side should not be ignored either, or the picture becomes skewed. AI cuts both ways: the same technology that makes attacks cheaper also strengthens defence, for instance in anomaly detection and faster incident response. But effective defence also needs architectures and processes that do not block it or send it in the wrong direction. The conclusion, then, is not alarmism. It is a sober reassessment of the variable now changing: the probability of an incident.

Complexity and concentration

Part of the cybersecurity risk is vendor-made or home-grown. Many architectures have grown quietly over the years, layer upon layer, and the real risk today often sits in their complexity. This affects IT environments. It equally affects software packages, database models and similar structures that this growth has made hard to secure. Worse still: anyone who no longer has an overview of what they run cannot secure it either. The obvious answer is focus and, ideally, simplification, and it is usually the right one: fewer active functions, less reachable surface, fewer interfaces.

Why a certificate alone is not enough

A clear consequence follows from these shifting variables. It is no longer enough to certify and document security alone. An audit describes a state at the time of the audit. It proves that a control exists and is documented. It does not prove that the control withstands a thinking, adaptive opponent. The distinction between proof of existence and proof of effectiveness is not new, but under the new conditions it becomes decisive. A certificate valid yesterday says little about an attack surface that keeps changing. Especially in fast-changing environments, and that is certainly true of AI systems and AI agents, the attack surface can change overnight.

The difference is very practical, not academic. Effectiveness is only proven once the same control is tested against a real attacker, for instance through controlled attack simulations. A board that, as part of its governance, only checks that a certificate or audit exists learns that something exists, not whether it would withstand an attack when it matters. The more useful question, then, is not only whether a certificate, audit or attestation exists. It is also whether the controls were tested under realistic conditions, and what that testing found.

A certificate proves compliance, not effectiveness against a real, adaptive attacker.

Back to the roots: architecture you can actually control

What matters in the age of AI is a resilient, and above all controllable, architecture, backed by genuine expertise on the board and in the executive team. Controllable means the organisation understands what it runs and can steer, in a real event, what it is responsible for. That means having your inventory as firmly in hand as your architecture. After a ransomware attack that had crippled parts of its systems for months, a board member told me that nobody had known the company ran 8,000 systems worldwide. Without that knowledge, a board is judging an architecture it cannot assess, and steering, in a real event, something it does not understand.

This does not require technical IT expertise. Nobody expects a board or an executive team to configure a firewall or write code. It requires judgement competence, meaning enough depth to recognise whether an answer holds up or merely reassures. Where that depth is missing, the board decides through proxies and advisers, through certificates, through vendor assurances, through the consensus in the room. And silence in the room, born of missing knowledge, often gets misread as consensus. Proxies are convenient, but they do not tell genuine protection apart from documented protection.

Research into judgement under opacity describes this pattern. When we cannot see through the basis of a claim, our only real choice, in the end, is between trust and rejection. The actual judgement never happens; that is exactly what occurs when a board decides on a security architecture without being able to read it. It hands its judgement over to the very source it should be scrutinising.

At leadership level, judgement competence does not mean being able to do everything yourself. It means being able to judge whether the answers hold up. A board should be able to name who in the organisation can explain the security architecture, and it should recognise the difference between an architecture that stays controllable in a real event and one that only works in normal operation. Where nobody can supply that explanation, what is missing is not a document. What is missing is a key competence at leadership level.

Responsibility stays with the board

The question of effective cybersecurity does not end with the technology. It ends with responsibility. Art. 754 OR ties the liability of those entrusted with management and administration to the care their role demands. That care can be distributed organisationally, but not handed away. Assessing a risk can be delegated to a certificate or a vendor; the judgement of whether the protection is real cannot. A certificate does not relieve the board of that task. It is an input into the judgement, not a substitute for it.