The refrigerators have been hacked. What Kerckhoffs can teach us.

Six timeless security principles for a world of Cloud, APIs and connected devices.

In recent months, the news has repeatedly reported on attackers remotely causing tonnes of food to spoil by manipulating the temperature settings of refrigeration systems in European supermarkets.¹ In France, attackers also attempted to raise the temperature of refrigeration units used to store blood products. Fortunately, the alarm systems were triggered in time, preventing the loss of valuable blood supplies.²

Initial reports indicate that several refrigeration systems were running outdated firmware, while some controllers were still protected by default passwords. This got me thinking. How could this have happened? What assumptions were made when these systems were designed? My mind immediately went back to something I learned at university: Auguste Kerckhoffs' second principle. It states that the security of a system should never depend on keeping its design or operation secret. In other words: no security through obscurity.

When I revisited the work of Auguste Kerckhoffs, I came across some surprising insights. Kerckhoffs was born in 1835 and published his work La Cryptographie Militaire in 1883.³ In it, he formulated six principles for designing secure cryptographic systems. Although his work was written in a military context and reflected the cryptographic practices of his time, the underlying principles remain remarkably relevant more than 140 years later. That is because they are not just about cryptography, but also about designing systems that need to be practical and usable. In this article, I explore these six principles and translate them into the modern world of software development, cloud architecture and cybersecurity.

Practically unbreakable

The idea that a cryptographic system should be practically unbreakable sounds fairly obvious. Yet things still go wrong on a regular basis. Recently, Indian company eMudhra made the headlines after eight of its intermediate CA certificates were found to have cryptographically weak private keys. Although the company stated that no certificates had been issued using these keys and that there was no evidence of misuse, the incident was serious enough to erode customer confidence and cause its share price to plummet.⁴ In the cybersecurity industry, trust takes years to build but can disappear overnight.

The best way to make a system more resilient is to use proven cryptographic algorithms and implementations, combined with strong keys. Rolling your own cryptography is almost never a good idea. Cryptography is a field in which brilliant minds have been trying to break each other's work for centuries. One of my favourite books, The Code Book⁵ by Simon Singh, describes this ongoing battle between code makers and code breakers. Whenever a new way of protecting information is invented, others will try to crack it.

But even if you choose the right technology and implement everything carefully yourself, you still depend on the security practices of others. If something goes wrong at a third party, your systems may be affected too. How to deal with this is addressed in one of Kerckhoffs' other principles.

No security through obscurity

Kerckhoffs' second principle is perhaps his best-known: the security of a system must never depend on keeping its design or operation secret. It immediately reminds me of one of my favourite childhood books: The Famous Five and the Secret Passage, in which the detectives set out to find, you guessed it, a secret passage. When they finally discover it, they find that it opens simply by pressing a wooden panel. There is no further security whatsoever. The Goonies handles this a little better, with its skeleton piano!

The lesson I took from this is that simply hiding something is not enough to secure it. The same applies to IT infrastructure. Today, scanning network ports or cracking weak passwords is relatively easy. AI lowers the barrier even further, allowing people with limited technical knowledge to attempt these attacks.

This is not, by the way, an argument for making all information public. Keeping the design of your system hidden can help keep some malicious actors at bay and make life more difficult for determined attackers. But it should never be the foundation of your security. If you have to choose between a proper lock and a wooden panel, choose the lock.

Manageable keys

You've accidentally committed a secret to Git. Something that happens to many developers at some point, and which means that the secret is no longer a secret. Or perhaps the certificate authority you use for your HTTPS certificates turns out to have generated private keys that are extremely weak.

Kerckhoffs argued that a cryptographic system should be designed so that the key can easily be replaced without having to modify the entire system. This principle is just as relevant today. After all, what happens when a key is leaked or is no longer considered secure?

Never store passwords, API keys or other secrets in your source code. Instead, use a secrets manager to make them available at runtime. This allows you to replace secrets without having to release a new version of your application.

If you use AWS, for example, take a look at AWS Secrets Manager. It allows you to manage passwords and other secrets centrally and rotate them automatically. AWS KMS is another useful service. Applications can use KMS for encryption and decryption without having direct access to the underlying key material.

No matter how carefully you handle secrets, you should always assume that one day a secret may be exposed. That is precisely why it is important to be able to replace it quickly and easily.

Suitable for the communication channel, practical and easy to use

In this final section, I will discuss Kerckhoffs' fourth, fifth and sixth principles together, translating them into a modern context.

Kerckhoffs placed considerable emphasis on portability. That was undoubtedly important on a muddy French battlefield in the nineteenth century, but modern systems face additional requirements, such as straightforward installation and remote management. After all, a secure system must not only be technically sound; it must also fit the way it is used.

This brings me to the fourth principle: a system must be suitable for the communication channel for which it is intended.

Consider the refrigerators mentioned at the beginning of this article. It makes sense for the manufacturer or store management to be able to monitor the temperature remotely, for example, to prevent food from spoiling because of a faulty refrigerator. But is it really necessary for someone to be able to change the temperature over the internet as well? Probably not. You could allow remote monitoring while requiring temperature adjustments to be made manually. This would significantly reduce the opportunities available to an attacker.

A similar principle can be found in the PSD2 standard for banking APIs. It distinguishes between APIs that only allow information to be retrieved (AIS) and APIs that enable actual transactions to be initiated (PIS). Different security requirements apply to each. While I would rather not have anyone know about my coffee addiction, I would certainly prefer that to having all my savings transferred to some mysterious cryptocurrency account.

But that is only part of the story. You could also place the refrigerators on an isolated network, allowing only the traffic that is strictly necessary. The manufacturer could supply such a network as a ready-to-use solution in the form of a small gateway that manages communication between the refrigerators and the internet. This means users do not have to worry about complicated network and security settings themselves. The manufacturer has already made the right choices for them, providing a good illustration of the fifth principle (practicality) and the sixth (ease of use).

The manufacturer's design choices can also play an important role when it comes to setting passwords. A simple default password may seem convenient, but it creates a major security vulnerability. By requiring users to set a unique password during installation, or by supplying devices with unique login credentials by default, you prevent an attacker from gaining access to an entire range of devices using a single password.

Conclusion

The lesson I take away from all this is that the security of a system ultimately depends on fundamental design decisions, such as correctly implementing proven standards.

Ease of use plays a major role in this. People generally choose the easiest option, even when it is not the safest one. Protect your users from themselves by making the right choice the only choice.

Studying Kerckhoffs' six principles has only strengthened my belief that good security starts with getting the fundamentals right. By taking principles such as least privilege and no security through obscurity into account from the very beginning, many problems can be prevented.

Some of these ideas about effective defence are thousands of years old. In The Art of War,⁶ written in the fifth century BC, Sun Tzu put it aptly: “Do not rely on the enemy not coming, but on our readiness to meet him.”

[1] https://www.theguardian.com/world/2026/oct/17/who-hacked-frances-supermarket-fridges

[2] https://nos.nl/artikel/2638045-franse-bloedbanken-ontsnappen-aan-schade-na-cyberaanval-op-koelinstallaties

[3] https://www.petitcolas.net/kerckhoffs/

[4] https://tweakers.net/nieuws/253680/emudhra-stopt-certificaattak-na-blunder-met-zwakke-private-keys.html

[5] https://simonsingh.net/books/the-code-book/

[6] http://geschiedenisklas.nl/wp-content/uploads/2018/03/the-art-of-war-nederlands.pdf