Many business owners assume encryption simply works once their ICT provider has set it up. A padlock icon in the browser bar, a checkbox marked ‘encrypted’ on the mail server, done. But a lock without key management protects no one. A slot without someone holding the key is not security, it is decoration. The question is not whether something is encrypted. The question is who holds the key, where it sits, and what happens when it expires, gets lost, or ends up in the wrong hands.
A Lock Is Useless Without Key Management
Encryption makes data unreadable to anyone who does not hold the right key. That key can be a digital certificate, a password, or a piece of code stored somewhere on a server. No key, no access, that is the basic idea. But a key nobody manages is about as useful as a house key left somewhere in the garden. It only does its job once someone knows where it is, who is allowed to use it, and when it needs replacing.
In practice, we see that many companies have no idea how many keys and certificates they actually have. They are scattered across mail servers, websites, VPN connections, backup systems and cloud applications. Often they were set up once by a supplier and never looked at again. That works fine, until the moment it does not.
Why ‘It’s Turned On’ Isn’t Enough
A certificate has an expiry date. If it lapses unnoticed, email traffic can suddenly be flagged as untrustworthy, a website can become unreachable, or a connection between systems can grind to a halt. This tends to happen at the worst possible moment, often in the middle of a busy period, simply because nobody had the expiry date in their calendar.
It gets trickier still when the key itself sits with an external party and nobody is quite sure who is responsible for it. A supplier who ‘will probably have it sorted’ is not a policy. It is an assumption. And assumptions about security do not hold up once something goes wrong, or once a regulator or client asks exactly how you have arranged this.
Measure First, Then Set Policy
We believe you cannot build policy around something you cannot see. That applies to encryption just as much as to any other part of your ICT. That is why we always start by measuring: which encryption is applied where, which certificates exist, when they expire, and who actually manages them right now.
That overview may sound like a formality, but it is exactly the piece that is missing in most companies. Without it, you do not know where you are exposed, and you cannot demonstrate that things are properly arranged. That matters increasingly in light of being demonstrably aligned with NIS2. Not because a box needs ticking on some list, but because you want to know for yourself that you are in control of your own data.
Ownership Before You Make Anything Mandatory
Once the overview exists, the next question follows: who owns which key, in everyday practice. Who gets notified when a certificate is due to expire in three months? Who is allowed to request a new key, and who approves it? A simple agreement is often enough, as long as everyone understands it.
The same logic applies here as with any other security question: policy comes before technology, and you bring people along before making something mandatory. A technical solution nobody understands, or feels responsible for, fades away within a year. So first establish who is responsible for what, and make sure that person is actually in a position to act in time.
What You Can Do Now
Start with a simple inventory. Ask your ICT partner, or whoever manages this, for a list of every certificate and key currently in use: on the website, in email, in VPN connections, in connections between systems. Note the expiry date for each one, and record who is responsible for renewal.
Then look critically at where keys sit with an external party without anyone in your organisation having visibility into them. Ask directly who manages the key there and how you can get insight into it. Once the overview is complete, agree on who receives notifications and who takes action. This is not a one-off task but something you repeat periodically, much like having a fire extinguisher checked on a regular schedule.
Encryption is one of the domains we think in at Motics. It belongs to a broader picture of how your company handles data and access, and it requires ongoing attention rather than a one-time setting. Only once you know what exists, who manages it, and when it expires, does encryption become what it is supposed to be: a lock you actually hold the key to.
A few questions we’re often asked
Should I manage all encryption myself, or can a supplier do it?
A supplier can absolutely handle the management side, that is often more practical anyway. What matters is that you know which keys exist, who manages them on your behalf, and that you have agreements in place about this. Without those agreements, you are relying on one person’s memory at an external party.
What happens if a certificate expires unnoticed?
It varies by situation, but usually you only notice once something fails: email that stops arriving, a website showing a warning, or a connection between systems breaking down. The real damage usually is not in the incident itself, but in the time it takes to figure out exactly what went wrong.
Is this only relevant for companies that fall under NIS2?
No. Having an overview of your encryption is useful for any company, regardless of whether you formally fall under NIS2. NIS2 simply makes it more visible that you need to be able to show this overview, but the real reason to do it is protecting your own data.
How do I know if our current encryption is actually properly arranged?
You only know for certain after an inventory of what exists, where it sits, and who manages it. A feeling of ‘it’s probably fine’ is exactly the kind of assumption we like to question. Only with a clear overview can you make it demonstrable instead of simply assuming it.
Want to know how encryption and key management are arranged within your own company? We are happy to help you build the overview that makes this clear.
