Why Would Anyone Need an Inventory of Their Own Encryption?

What encryption does your organization actually use, and where?

Not “we use industry-standard encryption.” Not “everything’s HTTPS.” The real answer we are looking for is which specific algorithms, in which systems, protecting which data, installed by whom, and when.

Most organizations, including good, well-run ones, cannot answer this today. Not because nobody cares. Because nobody ever had to write it down.

That’s the whole idea. Not a new concept, not a technical breakthrough; just the recognition that “we don’t actually know what’s in our own walls” is a real problem, and it’s getting harder to ignore.

Security teams have a saying: you can’t secure what you don’t know you have. It’s true of laptops, of software, of vendor relationships, and it is just as true of encryption, even though encryption is usually the thing that’s supposed to be doing the protecting.

A few real-world versions of the same problem, to make it concrete:

Here’s the part that makes this more than an abstract good idea: encryption ages. Not gracefully, either. It tends to be fine for years and then, occasionally, all at once, stop being fine. Sometimes because someone finds a flaw. Sometimes because computing power catches up to what used to be unbreakable.

Something is happening to encryption right now that will make headlines over the next few years, and it’s exactly this kind of aging-out event, at a scale the industry hasn’t dealt with before. We’ll get into what, specifically, later in this series. The short version is that a category of encryption almost everyone relies on today is on a clock, and organizations that don’t know what they’re running won’t know if the clock applies to them.

You can’t put something on a migration plan if you don’t know it exists.

That’s really the whole argument for an inventory, in one sentence. Everything else, which format to use, who should see it, what a regulator might ask about it, is a detail on top of that one idea.