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

This is Part 2 of the series.

Part 1 looked at the post-quantum threat, EU regulatory drivers and why every mobile banking app now needs a Cryptographic Bill of Materials (CBOM) - a clear inventory of keys, algorithms and high-risk use cases. In this second part, we explore a tougher question: once you can see your cryptography, how do you turn that visibility into a strategic capability to change it at the speed regulators and attackers are moving?

For leadership teams, this is where mobile cryptography stops being a “developer detail” and becomes a resilience discussion. Supervisors will not only ask what algorithms you use, but how quickly you can move away from a broken one, how confident you are in your libraries and platforms, and how your plans align to the EU’s post-quantum timelines. Banks that treat the CBOM as a living risk instrument, rather than a static document, will be in a much stronger position.

In practical terms, that journey starts deep in the stack: which libraries you rely on, how they are validated, how they map onto OWASP and NIST guidance, and where you will source PQC-ready capabilities. From there, crypto agility becomes an architectural property of your mobile channel, not a one-off project. With that mindset, we can now look at the cryptographic libraries and standards landscape that sit behind a CBOM for mobile banking apps.

Libraries

Cryptographic Bill of Materials (CBOM) is not complete if it only lists keys and algorithms—it must also identify which cryptographic libraries implement those algorithms, as well as what is provided and what is being used. This is critical for:

• Compliance: Ensuring libraries are FIPS 140-2/140-3 validated or equivalent.
• Security posture: Detecting outdated or vulnerable libraries.
• PQC readiness: Confirming libraries support algorithm migration.
• iOS (Objective-C / Swift)
  • CommonCrypto: Apple’s built-in C-based library for hashing, symmetric encryption (AES), HMAC, etc.
  • CryptoKit: A modern Swift framework introduced in iOS 13 for secure hashing, symmetric and asymmetric cryptography.
• Android (Java / Kotlin)
  • Java Cryptography Architecture (JCA): Built into the Android SDK, provides APIs for encryption, signatures, key generation.
  • BouncyCastle: A popular provider for extended algorithms beyond JCA defaults.
    • Crypto-browserify (Node.js crypto polyfill for React Native)
    • cordova-plugin-crypto (wraps native crypto)
    • react-native-keychain (for secure storage, often combined with crypto)
    • Dart-based libraries
    1. PSD2
    2. NIS2 Directive
    3. PCI DSS
    4. DORA

Common Crypto Libraries in Banking Apps

The main native cryptographic libraries can be divided into Native and Cross Platform parts:

Platform-specific libraries

In addition, mobile app developers often develop their apps using cross platform frameworks which allows calling platform channels to invoke native crypto libraries which have the advantage of supporting hardware-backed security. On top, additional plug-ins are available, such as:

Applications may use OpenSSL library for the TLS, however, a new version of OpenSSL with support for PQC algorithm i.e., ML-KEM is open for testing and use: Release OpenSSL 3.5.0 · openssl/openssl · GitHub (pending FIPS 140-3 validation). Most financial and critical indsutries use crypto libraries and toolboxes from vendors for more security and its Intellectual Property characteristics.

Understanding compliance requirements for banking apps’ Crypto

Mobile banking apps are now the primary channel for remote banking, making their cryptographic foundations subject to strict regulatory oversight and industry best practices.

Regulatory Obligations

Across the following four EU and industry frameworks, namely

The common theme relating to cryptography is that cryptography isn’t treated as a “nice-to-have” security feature, it is the control mechanism that regulators expect businesses to prove the authenticity, integrity, confidentiality, and operational resilience end-to-end. Some of these regulations have come into effect and some of them are going to be implemented on a scale across the EU soon. The image below consolidates the use, importance, methodology and importance of the use of Cryptography in the information technology domain, especially in payments.

Industry-wide Best Practices

For mobile applications, there has been quite an advancement in the protection mechanisms in the last 10 years. Bank and regulators alike are aware of the growing fraud in this domain. While regulators help protect the economy and businesses at a larger scale, technology enthusiasts and experts have banned together to create a set of security baseline, leading the standards in the industry, for protecting mobile applications in today’s world. This is where OWASP foundation comes in, with experts from all around the world who created open guides for improving the security posture of mobile applications, making them resilient against growing threats.

Following these practices from OWASP and NIST establish a good baseline of security posture that gives a head-start with complying to regulatory requirements. With the scope of Cryptography as a topic for this paper, the general recommendations from OWASP and NIST can be narrowed down in the following way:

Crypto agility is a term that has been going around, and is often defined as the ability of a system or organization to rapidly adapt its cryptographic mechanisms and algorithms in response to changing threats, technological advances, or vulnerabilities. It implies in practice a strategic approach that combines architectural flexibility, automated governance, and operational resilience.

For mobile banking apps, crypto agility means designing systems that can evolve without disruption. It requires decoupling cryptographic operations from business logic so that algorithms can be swapped without rewriting the app. It demands centralized policy control, enabling banks to enforce algorithm changes remotely, and automated governance to manage key lifecycles, algorithm deprecation, and compliance reporting.

Cryptography is deeply embedded in application logic, powering functions like transaction signing, device binding, JWT token protection, and secure storage. The challenge is compounded by slow update cycles, fragmented ecosystems, and backward compatibility issues. In short, crypto agility cannot be achieved through ad hoc patches; it requires a fundamental redesign of cryptographic architecture. In some cases, specialized mobile security vendors can help accelerate the journey to crypto agility by providing a crypto toolbox designed for adaptability. These toolboxes offer modular cryptographic layers that abstract complexity and allow banks to update to NIST-accepted algorithms.

The true move to crypto agility in mobile applications is not that far but today the regulatory bodies require proper use of cryptography in sensitive operations and require a full disclosure for certification and compliance reasons. If you want to learn more about crypto agility and what it could mean for your organizations, reach out to Cryptomathic team for more information. Similarly, mobile applications are continuously evolving and keeping up with latest threats, reach out to us to learn more about how to protect your financial applications.

Next steps: build your CBOM and plan for crypto agility

Mobile banking apps are now the primary channel for remote banking, so cryptography is no longer a back-end concern; it is a front-line resilience control.

Across PSD2, NIS2, PCI DSS, and DORA, the direction is consistent: financial institutions must be able to demonstrate what cryptography they use, who controls it, and how it will be updated as threats evolve, including post-quantum risk. In practice, this comes down to two deliverables: (1) a Cryptographic Bill of Materials (CBOM) that inventories the app’s keys, algorithms, certificates, and cryptographic libraries, and (2) crypto-agility processes that make rotation and algorithm change safe, repeatable, and auditable.

To help you get started, we’ve created a CBOM template for mobile banking apps aligned with the fields discussed in this paper (assets, ownership, lifecycle, rotation, and PQC impact). Download the template and populate it for your mobile app as a first step toward quantifying risk and planning remediation. If you’d like a fast-track assessment, contact Cryptomathic to review your cryptographic inventory, identify PQC-exposed use cases, and define a realistic migration and governance roadmap.

Together, Part 1 (CBOM and regulatory drivers) and Part 2 (libraries, best practices and crypto agility) provide a practical path for issuers to demonstrate post-quantum readiness for mobile banking under DORA, NIS2 and related frameworks; if you would like to discuss how this applies to your own mobile banking portfolio, please reach out to the Cryptomathic team.