Post-Quantum Readiness for Mobile Banking: Why CBOM and Crypto Agility Matter for DORA (Part 1)

Mobile banking apps now sit on the front line of operational resilience. They rely on cryptography for almost everything that matters - user authentication, device binding, secure storage and transaction authorization - at the very moment when today’s public-key schemes (RSA and ECC) are expected to become vulnerable to sufficiently capable quantum computers and “harvest now, decrypt later” attacks.

This first part of a two-part series examines what that shift means for issuers under EU resilience and cybersecurity expectations (notably DORA, NIS2 and the Cyber Resilience Act), and why two practical capabilities are becoming essential evidence of control: a Cryptographic Bill of Materials (CBOM) for the mobile app and a crypto-agile development and operations model that can rotate keys and upgrade algorithms, including a transition to post-quantum cryptography for high-risk use cases. Part 2 will build on this by looking at cryptographic libraries, industry best practices and how to embed crypto agility into mobile architectures.

Regulations explicitly require:

NIS 2, Article 21(1):

• Implement “appropriate and proportionate technical and organizational measures to manage risks posed to the security of network and information systems.”
• Financial entities must ensure their cryptographic technology remains resilient against evolving ‘cryptanalysis and cyber threats’.
• Proactive monitoring is also called out, with reference to ‘threats from quantum advancements’ as a reason why organizations must remain aware and abreast of developments in cryptographic techniques
• Algorithm updates are mandated by DORA, and organizations must have a policy that includes provisions for updating or changing cryptographic technology when threats emerge.
• Adopt “a flexible, risk-based approach to deal with the dynamic landscape of cryptographic threats, including threats from quantum advancements.”
• “Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.”

DORA RTS (2024/1774), Article 6 and Recital 9:

CRA Annex I Section 1(1):

With a focus on risk management, inventorying, reporting suspected HNDL attacks and resilience testing, the legislation applies stringency to the way financial bodies must consider their readiness.

For issuers of mobile banking apps, this means:

1. Maintaining a Cryptographic Bill of Materials (CBOM) for mobile apps that lists all keys and algorithms.
2. Understanding the Compliance requirements on these assets (both regulatory requirements but also standard internal compliance requirements to mitigate threats).
3. Implementing crypto agility practices in their development framework to be able to rotate keys but also algorithms in due time incl. migration to post-quantum cryptography (PQC) adoption by 2030 for sensitive applications.
   • By 31/12/2026: plan PQC migration and set road maps
   • By 31/12/2030: “PQC transition for high risk use cases has been completed” - since user authentication (usually based on jwt tokens) and transaction signing (usually based on ECDSA or HMAC) are triggered on mobile apps, it is evident that mobile banking apps will be regarded as high-risk use case.

To get started with CBOM, we look at CycloneDX’s (which is the international standard for Bill of Materials for software products) Authoritative Guide to CBOM, which casts light on the importance of it, enabling detailed representation of cryptographic assets within a system. This includes algorithms, keys, certificates, and their relationships to software components. Such granularity allows organizations to assess the strength of their cryptographic implementations and address weaknesses and vulnerabilities like the use of deprecated algorithms or expired certificates.

Most bank CISOs will regard their mobile banking app as very critical since it is now the first media being used to conduct financial operations. Reading the EU coordinated roadmap / NIS Cooperation Group deliverable, this means that they need

Building a CBOM for Mobile Apps

Keys:

The first step in creating a CBOM that shows Crypto Agility and complies to standards and regulations like DORA and NIS2, is to know what libraries, algorithms, certificates, tokens and keys etc are present in your system. The table below shows a sample collection of information about the cryptographic materials used in different parts of a Mobile Payment Wallet application. The list below is indicative only:

The assets marked in purple are outside of your control (apple or Google)

The assets marked in green are typically handled on the server side.

The assets marked in orange are assets which you need to control on your app development lifecycle

A snippet from a CBOM for a Mobile Payment Wallet could look like this for a particular algorithm or key:

In this first part, we have focused on why EU regulations and the EU PQC roadmap make a CBOM for mobile banking apps essential, and how to start inventorying keys and algorithms. In Part 2, we will build on this foundation by looking at cryptographic libraries, compliance frameworks and how to achieve practical crypto agility for mobile banking under DORA and NIS2.

Future-proof your mobile app security architecture – Learn how to defend against AI-powered attacks, implement crypto agility, and build quantum-resilient mobile banking infrastructure. Download the guide now.