Asset Management

The foundation everything else depends on

DORA Article 8 requires financial entities to identify, classify and document all ICT-supported business functions, the people and roles around them, and the underlying ICT assets. Article 8(4) goes further for anything supporting critical or important functions: the register must be specific, current, and good enough to act on.

Without an accurate asset register, everything downstream wobbles. Business impact analysis cannot size properly. Recovery time objectives become guesses. The Register of Information ends up filled with placeholders. The 4-hour major-incident notification window becomes impossible to hit because nobody can answer what is actually affected. Threat-led penetration testing scopes get drawn around what is convenient rather than what is critical.

The most common failure we see is treating the asset register as a CMDB export rather than a risk artefact. The CMDB knows what runs where. The risk register needs to know what depends on what, who owns it, what would happen if it stopped, and who you would call. That is a different question, and a different document.

The cryptographic layer most asset registers are missing

Most ICT asset registers do not capture cryptographic properties of the assets they list. Which algorithms are in use, what key lengths, where the keys live, how often they rotate, which crypto is embedded by a vendor and which is system-level, what libraries are involved, whether hardware acceleration is in play. These attributes have been left out for a simple reason: cryptography used to be a stable background assumption.

That assumption no longer holds. NIST finalised the first post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. Migration is now an operational question, not a research one.

DORA exposes this in three places without ever using the word "cryptography". Article 8 requires the asset register. Article 9 requires appropriate ICT security and prevention controls. Article 25 requires ICT service contracts to specify security standards. Cryptography sits inside all three. None of them name it, which is why the column does not exist in most registers, and why examiners will start asking once the wider PQC conversation reaches them.

"Harvest now, decrypt later" is the practical risk that makes this urgent. Anything with a long confidentiality horizon is exposed today: mortgage portfolios, life insurance contracts, KYC archives, M&A diligence data rooms, pension records, long-running litigation materials. An attacker exfiltrating ciphertext now and holding it for the arrival of a cryptographically relevant quantum computer is making a perfectly rational bet. The asset register is the only place in the organisation that can identify what is at risk and where to prioritise.

Regulators are moving. EU Commission Recommendation 2024/1101 calls for coordinated PQC implementation across Member States. ENISA has published successive PQC reports. The UK NCSC has set out a migration timeline: planning by 2028, completion by 2035. Germany's BSI has updated TR-02102 with PQC guidance. DORA examiners will not stay quiet on this for long.

What this means in practical terms for the asset register:

• Add cryptographic-inventory columns now: algorithm, key size, library and version, vendor dependency, lifecycle state
• Identify long-confidentiality data and the assets that hold or transmit it
• Build a crypto-agility roadmap that ties into the asset lifecycle, not a separate project
• Bring the cryptographic inventory into the same governance forum that signs off the rest of the asset register

For organisations that want a deeper specialist view, our sister practice at INKASEC covers post-quantum cryptography readiness directly.