Cybersecurity cannot be certified

There is a basic misunderstanding in the way we keep talking about cybersecurity: the idea that security can be certified the way an industrial object is certified.

A screw can be certified. I can define what material it should be made of, what tolerances it should respect, how much force it should bear, in what conditions it should work. I can put it through repeatable tests, compare the result with a standard and say that this screw, within certain conditions, meets certain requirements.

With a cybersecurity assessment this scheme simply does not hold.

Imagine a serious piece of work that lasts three or four months. You study the architecture, you analyse configurations and code, you run tests, you reconstruct the relationships between systems, you look at permissions, integrations, APIs, application behaviour. You proceed by hypotheses, you change direction, you dig into whatever looks anomalous. In the end the report arrives, someone signs it, and perhaps that document enters a certification process.

But what was actually certified?

Not the impenetrability of the system, because no serious professional could claim it. Not the absence of vulnerabilities, because a vulnerability may simply not have been found. Not the existence of a universally valid method, because real security assessments are not an industrial recipe repeated the same way in every environment. There are frameworks, procedures and good practices, of course, but the value of an assessment comes precisely from the ability to adapt to the context.

A complex environment does not let itself be analysed by following a checklist alone. At some point you have to understand where to look, which relationships to explore, which assumptions to question. Two formally similar infrastructures can require completely different approaches. A vulnerability can emerge not from an obvious mistake, but from the interaction between elements that, taken one by one, look correct.

This is why the idea of certifying "the method" often risks becoming a bureaucratic fiction. You can certify that a process was followed. You can certify that certain checks were performed. But going from there to saying that security has been certified is an enormous leap.

The difference becomes clear with a very simple example.

My team and I work four months on a system. We do a good job, we are competent, we find several problems, we produce a detailed report and in the end we sign it. The following day a new, far more powerful artificial intelligence model arrives. We give it access to the same code, the same documentation, the same configurations, and in a tenth of the time it finds a critical vulnerability we had not seen.

That vulnerability was not born the next day.

It was already there while we were signing.

At that point the question is not whether the model invalidated our certification. The real issue is more uncomfortable: that certification had never certified the security of the system. It had certified, at most, the limit of our ability to analyse it at that moment.

And this is where the discussion about certification is inevitably tied to the one about responsibility.

The signature is not only there to declare that a job was done well. It also serves to build an accountable party. If something goes wrong, there is someone who signed, someone who can be called to answer.

This arrangement worked for a long time because technical quality and personal responsibility often overlapped. The professional did the work, checked it and took responsibility for it. With artificial intelligence this overlap starts to break.

If an automated system becomes better than me at security analysis, what sense does it make for me to be the one who certifies its work?

I can read its report, I can check some steps, I can verify that the conclusions are consistent. But if the machine is genuinely better than me at finding vulnerabilities, I cannot guarantee that it did not make a mistake without redoing the whole work. And if I could redo it just as effectively, then it would not be true that the machine is better than me.

The signature, at that point, risks becoming a purely administrative construction. It no longer serves to guarantee the technical value of the result. It serves to keep someone inside the process because the legal and organisational system wants a name at the bottom of the page.

The medical example makes the problem even clearer.

A doctor can be excellent, but remains a human being. Their performance is not perfectly constant. They can be more tired, more lucid, more focused, they can be coming off a particularly heavy shift. The quality of their decision can vary.

A model that analyses an X-ray, a CT scan or a report can certainly be wrong, but it is not subject to the same factors. Its computational ability does not change because it is three in the morning. It does not reach the fiftieth analysis of the day with less attention than the first. If it was built well, its performance tends to be far more stable.

This does not mean it is infallible.

It means the problem changes in nature.

If an automated system becomes statistically more reliable than a human being, it will still commit a certain percentage of errors. The error does not disappear. It becomes, though, a measurable risk, a residual statistical error.

And this is where our obsession with personal responsibility begins to show its limits.

If a machine, on average, is wrong less often than a doctor, it would make little sense to keep the doctor in the process only because, when something goes wrong, we want a person to point to as responsible. It would be even more absurd if their presence did not improve the result, but served only to add a signature.

At that point we have to accept a very simple thing: not all responsibility can be thought of as the search for individual blame. Some systems work on a probabilistic basis. They can be better than any available alternative and still be wrong.

The question then becomes how to manage that error, how to measure it, how to reduce it and how to compensate those who suffer its consequences. But this is a matter of risk management, not of quality certification.

And this is exactly what happens in cybersecurity.

No signature turns an assessment into a truth. No certificate removes the fact that the system may contain something nobody has found yet. No procedure, however serious, changes the nature of the problem.

Security is a condition continuously negotiated between what we know today and what we will discover tomorrow.

This is why the real value does not lie in producing a document that closes the problem, but in building a process that stays open. Continuous review of projects, analysis during implementation, verification of changes, observation of the environment, repeated audits, the ability to go back over decisions considered correct months earlier.

This kind of security is more uncomfortable, because it does not produce the reassuring moment of "we are certified".

It does not end.

It does not let management tick a green box and consider the problem solved.

And perhaps precisely for this reason the market often prefers to sell us the opposite idea.

A company calls a consulting firm and, instead of getting someone who truly enters the processes, who studies how architectural decisions are made and who accompanies the evolution of the systems, it finds itself in front of a catalogue of products.

Certified products.

Certified solutions.

Certified methodologies.

As if the sum of certified objects automatically produced a secure environment.

It is an extremely convenient way to turn a complex technical problem into an administrative practice.

You buy the product, you fill in the documentation, you pass the audit, you get the certificate.

The problem is that an attacker does not attack the certificate.

They attack the system.

And the system does not care whether someone signed a document six months earlier.

This is the point on which we should be far more radical.

Certifying compliance with a standard can make sense. Certifying that an organisation has implemented certain procedures can make sense. Certifying that a given control was performed can make sense.

But calling all of this "security certification" produces an illusion.

Security is not an absolute attribute assigned to a system after an audit. It is an always provisional measure of our ability to find problems before someone else does.

The more artificial intelligence tools advance, the more this reality will become obvious.

If tomorrow a model can do in a few hours what today takes months of human work, the amount of time spent on the analysis will no longer be a good indicator of its value. If that model finds vulnerabilities that a certified team did not find, the team's signature does not suddenly become useless: it simply becomes clear that it had never been a technical guarantee.

It was a photograph.

Partial.

Temporary.

Tied to the abilities of whoever was looking.

And at that point we may have to stop using certification as a form of collective reassurance and start describing security for what it really is: a matter of probability, analytical ability, speed of reaction and continuous risk management.

A screw can be certified to withstand a certain force.

An IT infrastructure cannot be certified to withstand what we still cannot see.

And if the next day a machine finds in ten minutes what four months of analysis had not found, it has not made security useless.

It has only torn the stamp off the page and reminded us that the stamp had never been security.