An inventory that records algorithm, key length and owner
The MAS advisory of February 2024 asks financial institutions to build crypto-agility and maintain an inventory of cryptographic assets, recording the algorithm, the key length, who owns it, and the system it sits in. That is a register, not a project plan, and it is the part most teams are missing.
Four fields, and the fourth one is the hard one
Algorithm and key length come from reading the estate. Owner and system come from your organisation. Only the first two can be automated, and pretending otherwise is how registers go stale.
Algorithm
RSA, ECDSA, ECDH, AES, SHA-1, MD5, and the post-quantum replacements already in use. Classified against the quantum model rather than against a list of deprecated names.
Key length
Read where the code declares it, including the places a text search misses because the size arrives through a variable or a configuration file.
System
The application, deployment, environment and asset that a finding belongs to, so the register answers "which system?" and not only "which file?".
Owner
A named person or team per finding, set once in the workbench and carried into every report, wave and evidence pack.
The cryptographic register in the workbench, with algorithm, application, evidence and wave.
Three questions that need more than a slide
| The question | What a defensible answer looks like |
|---|---|
| Where is cryptography used across the estate? | An inventory built from code, images, cloud configuration and endpoints, not a survey of what teams remember |
| How exposed are we to a quantum attack? | Each finding classified by algorithm, by exposure and by whether it actually ships |
| What is the plan, and who owns it? | Migration waves with owners, target dates and a stated coverage boundary |
What we do not do
We do not connect to your databases, read business records, or issue anything that claims compliance. The inventory is evidence, and your attestation is yours. Where a requirement comes from MAS or CSA, the site links to the published source so your compliance team can check the interpretation rather than take ours.
Private code is scanned either through a linked GitHub, GitLab or Bitbucket account, or by the offline scanner running inside your network, where source never leaves your side and only the report is uploaded.