Assess quantum-related technology risk within the institution's existing ICT, cybersecurity and operational resilience framework. Identify material exposures, business impact and risk treatment options.
Post-Quantum Cryptography
Quantum Readiness for the UAE Financial Sector.
The practical starting point is a complete cryptographic inventory, linked to data sensitivity, business ownership, crypto-agility and third-party dependencies, not simply a list of certificates.
Cryptographic asset inventory
Identify and classify cryptographic assets across
systems, applications, networks, HSMs, cloud
services and third parties. Map ownership,
sensitivity, dependencies and crypto-agility.
CBUAE Regulatory Context
Operational resilience meets quantum readiness.
Operational resilience and ICT cybersecurity requirements for Licensed Financial Institutions, effective 14 September 2026.
UAE Regulatory Reference
CBUAE Regulation C 1/2026
Operational Risk and Operational Resilience
Article 8
ICT and Cybersecurity Management
Effective Date
14
SEP
2026
Four areas to address
Select an area to exploreIdentify and classify cryptographic assets across systems, applications, networks, HSMs, cloud services and third parties. Map ownership, sensitivity, dependencies and crypto-agility.
Define phased migration options for priority assets, including crypto-agility improvements, hybrid approaches and technology refresh dependencies.
Keep emerging technology and quantum-related cyber risk within information security and operational resilience governance, with appropriate senior management and board visibility.
Scope
Banks and other Licensed Financial
Institutions (LFIs)
Finance companies and payment
service providers
Other CBUAE-regulated financial
institutions, as applicable
The practical starting point
A complete cryptographic inventory linked to data sensitivity, business ownership, crypto-agility and third-party dependencies — not simply a list of certificates.
Why the urgency
Harvest now.
Decrypt later.
Sensitive encrypted traffic may be captured today and potentially decrypted later if future quantum capabilities break the public-key mechanisms protecting it.
01
Traffic captured
TLS 1.3
02
Stored over time
Hybrid key exchange
03
Future decryption risk
Confidentiality protection
The threat
The risk begins before a quantum computer exists.
Adversaries do not need a quantum computer to start — they need storage. And storage is cheap!
Why captured data matters
Captured traffic keeps its value for as long as the data inside it matters: account data, customer identity, interbank messages, board communications.
Transition timelines
NIST deprecates RSA and ECC in 2030 and disallows them in 2035. Data with a confidentiality life beyond that horizon is exposed today (Mosca’s inequality).
Where the weakness sits
Symmetric encryption (AES-256) is fine. The weak link is the key exchange that protects it.
The fix available now
A practical step toward quantum-resistant confidentiality.
TLS 1.3 with hybrid key exchange — X25519 + ML-KEM-768 (FIPS 203).
Supported today
Supported today by OpenSSL 3.5+, Chrome, Firefox, Edge, Safari, Cloudflare, AWS and Azure front doors. No certificate change required.
Why hybrid
Hybrid means classical security is never weaker than before, and quantum security is added — the safe default while ML-DSA certificates mature.
Priority order
Priority order: internet edge, interbank and payment links, VPNs, then internal east-west.
A staged transition: Hybrid key exchange can address confidentiality exposure sooner, while certificate and digital-signature migration should be treated as a longer, staged programme.
Reference: NIST Post-Quantum Cryptography programme and transition guidance, 2025–2026. Statements reproduced from the supplied presentation; validate technical support and standards timelines before publication.
Technical considerations
What changes on the wire.
Three technical notes before you plan
Post-quantum certificates are bigger, encodings are evolving, and TLS 1.3 changed what a passive sensor can see. Select a topic below to explore the implications for cryptographic discovery and migration.
Certificate footprint / illustrative comparison
3.35×
approximate certificate size
in the source material
Relative comparison only · ML-DSA-65
and ML-DSA-87 are larger
01 / Payload impact
ML-DSA certificates are heavier
A certificate signed with ML-DSA-44 carries about 3.35× the bytes of today’s ECDSA equivalent; ML-DSA-65 and -87 more. Handshakes cross the TCP initial window, TLS record limits and some middleboxes. Plan capacity on edge devices, HSM throughput and constrained clients before switching issuance.
Plan capacity before switching issuance
Certificate encoding / conceptual illustration
X.509
ASN.1 / DER
Classical encoding overhead
C509
CBOR encoding
More compact representation
Visual is schematic, not a scale measurement.
02 / Encoding efficiency
C509: CBOR-encoded X.509
IETF (COSE working group) defines a compact CBOR encoding of X.509 certificates — C509 — that strips the ASN.1/DER overhead and shrinks classical certificates substantially. For ML-DSA the public key and signature dominate, so C509 helps at the margin, not at the core. Track it for IoT and constrained links.
IETF · draft-ietf-cose-cbor-encoded-cert
Handshake visibility / TLS 1.3
CLIENT
TLS 1.3
Certificate encrypted
SERVER
Passive visibility
ClientHello / ServerHello,
SNI and key-exchange groups
Inventory approach
Active scanning + ntopng
flow visibility
03 / Sensor visibility
TLS 1.3 hides the certificate
In TLS 1.3 the server certificate is sent encrypted. A passive sensor sees only ClientHello and ServerHello: SNI, offered and selected key-exchange groups. Products built on passive certificate capture — ISARA, CryptoNext and similar — go blind on modern endpoints. That is why our inventory pairs active scanning with ntopng flow visibility rather than relying on passive certificate extraction.
Encrypted server certificate in TLS 1.3
Implementation focus
Capacity planning, compact encoding,
and reliable cryptographic visibility
need to be addressed together before
a broad PQC migration.
Cryptographic asset inventory
Three layers,
One cryptographic register.
Build the baseline first. Reconcile what is discovered, what has been issued, and what is observed in traffic — so completeness is measured, not assumed.
Select a layer to explore its contribution
UNIFIED CRYPTOGRAPHIC ASSET REGISTER
ONE REGISTER · MEASURABLE COVERAGE
FIELD 01
Asset
FIELD 02
Owner
FIELD 03
Algorithm
FIELD 04
Protocol
FIELD 05
PQC readiness
FIELD 06
Counterparties
SOURCE 01
Discovered
rTrust CLM Core — active network scanning, TLS versions, certificate chains, key algorithms and hybrid key-exchange support.
Then add business context and readiness
Join the register to CMDB and data classification, sensitivity, data lifetime and ownership.
THE DELIVERABLE
One register with owner, algorithm, protocol, PQC readiness and counterparties per asset — plus a repeatable procedure and measurable coverage metric.
Our solution / Certificate lifecycle management
rTrust CLM Core.
Inventory. Governance. Automation.
Centralised control of every certificate, decentralized issuance for the teams that need them.
Explore six capabilities
Select a capability to explore
rTrust CLM Core
Certificate control plane
01 / CAPABILITY
Discovery
Network scanning, Certificate Transparency, smart discovery across cloud, containers, appliances and IoT.
Standards & deployment
X.509 v3 · CRLv2 · RFC 5280 · FIPS 204 ML-DSA today · RPM, Docker or Kubernetes · full REST API · Bouncy Castle cryptography.
Seen in the product
Hybrid TLS and ML-DSA certificates, in one inventory.
Illustrative live records from rTrust CLM Core, September 2026. Explore the inventory, two certificate examples and the dynamic dashboard.
Endpoint discovery
Inventory record
One host. Multiple endpoints.
Network inventory with TLS context, hybrid key exchange and first-seen / last-seen evidence.
rn-trust.com
Discovered endpoints described
in the presentation
ENDPOINT
443
TCP / TLS
ENDPOINT
2083
TCP / TLS
ENDPOINT
8443
TCP / TLS
TLS 1.2 / 1.3 observed
Hybrid key exchange negotiated
First seen · audit trail
Last seen · audit trail
Certificate record
Certificate evidence
Classical signature. PQC-ready host.
A public ECDSA P-256 certificate marked Host PQC Ready.
Certificate key
ECDSA P-256
Host assessment
Host PQC Ready
Certificate type
Public certificate
Confidentiality protection from hybrid
key exchange and migration of certificate
signatures are separate considerations.
A PQC-ready host can still use a
classical certificate.
Post-quantum certificate record
Certificate evidence
ML-DSA, already in the inventory.
Post-quantum key and signature details, with issuance and grading handled by the same inventory.
Key type
mldsa-44
Signature
ML-DSA-87
Issuer
rTrust PKI post-quantum CA
The certificate is inventoried, chained
and graded like any other certificate —
demonstrating visibility across classical
and post-quantum environments.
Evidence for risk and compliance
Dashboard views
A dynamic certificate dashboard.
Explore the report dimensions from the presentation. The chart below is schematic, not real certificate counts.
Certificates by status
An overview of certificate lifecycle
status across inventoried assets.
Illustrative chart pattern ·
no metrics or counts represented
What the evidence shows
Inventory view: rn-trust.com on ports 443, 2083 and 8443 — TLS 1.3 and 1.2, hybrid key exchange negotiated. First seen / last seen provide the audit trail.
Partner · Network Visibility
ntopng with nProbe.
See the connections.
Open-source traffic analysis with commercial collection and support — the observed layer of your cryptographic inventory. Map third-party dependencies, verify scan coverage and add network visibility to PQC readiness.
Bank Network
Routers · Firewalls · Switches
nProbe
NetFlow v5/v9 · IPFIX · sFlow
ntopng
Central dependency visibility
SaaS provider
Cloud region
Card network
Correspondent bank
STEP 01
Observe the network
Flow records identify communicating endpoints, connections and third-party dependencies.
STEP 02
Compare active discovery
Reconcile flow-observed TLS servers with assets discovered by rTrust CLM Core active scans.
STEP 03
Identify coverage gaps
Servers appearing in flows but absent from the scan identify gaps to investigate. Record the result as coverage evidence.
01 / PACKET COLLECTION
SPAN, TAP or cloud mirroring
Packet-level visibility at selected network points provides access to handshake metadata unavailable in basic NetFlow records.
02 / PASSIVE ANALYSIS
TLS metadata and Zeek
Session context includes TLS version, SNI, cipher, ALPN and fingerprints. Zeek ssl.log provides negotiated key-exchange-group evidence.
03 / ACTIVE VALIDATION
rTrust CLM Core scanning
Active scanning supplies authoritative certificate, algorithm and hybrid-key-exchange attributes for the cryptographic inventory.
01 / OBSERVED LAYER
Third-party dependency mapping
Every encrypted flow to a SaaS provider, cloud region, card network or correspondent bank becomes a third-party dependency that can be named, counted and dated.
CAPABILITY 01
Layer-7 Context
nDPI classifies 450+ applications. nProbe collects NetFlow v5/v9, IPFIX and sFlow from routers, firewalls and switches into one view.
CAPABILITY 02
Remote & Cloud Collection
nProbe sensors per site and cloud packet mirroring across AWS, Azure and GCP feed central ntopng through ZMQ or Kafka.
CAPABILITY 03
Operated by RNTrust
Delivered under the MSP contract, licensed, supported and patched, providing an operational counterpart for the bank's third-party risk team.
Flows tell you who is talking and to whom.
Active scans provide the cryptographic attributes.
NetFlow records alone do not contain TLS certificate or handshake metadata. Packet sensors, Zeek and active scanning complement the dependency map to create a more complete cryptographic inventory.
Passive monitoring / network architecture
The network architecture challenge.
Where to look, with what, and what each vantage point can and cannot see. Explore the three collection methods, then see how they work together in the recommended deployment.
Choose a monitoring method
Core principle: a few selected packet sensors, broad flow export and active scanning provide complementary evidence.
Visibility blueprint / schematic
Method selected
Illustrative vantage points — the selected method lights up its telemetry path
SPAN / Mirror Ports
What it provides
Cheapest and fastest; sees full packets on the local switch.
What it cannot guarantee
Misses traffic on other switches and VLANs; can drop under load; sees only one hop.
Recommended vantage: Internet edge, DMZ, DC core
Recommended layout
Three evidence layers. One complete picture.
01
Flow collection
Central ntopng + nProbe collect NetFlow/IPFIX/sFlow from every firewall and core router.
Dependencies, third parties, coverage check
02
Packet sensors
Three or four SPAN/TAP sensors at DC core, DMZ and internet edge, plus cloud mirroring.
Handshake metadata and client hybrid offers
03
Active discovery
rTrust CLM Core actively scans every range. TLS 1.3 encrypts certificates, making active scans essential.
Authoritative TLS, certificate and hybrid-KEX attributes
Key architectural decision: you do not need to TAP everything. Flows establish the map, selected sensors provide handshake context, and active scans confirm cryptographic attributes.
Completing the inventory
What the network cannot see and how we close it.
A bank's cryptography is not only on the wire. Six categories need a different source.
BEYOND NETWORK TELEMETRY
ILLUSTRATIVE COVERAGE PATH · NOT LIVE DATA
CATEGORY 01 / 06
HSM and KMS keys
Payment, PIN, EMV, SWIFT, 3-D Secure, cloud KMS, TDE and tokenisation keys.
Required additional source
Partition and KMS exports.
Visibility boundary
Partition and KMS exports
Illustrative source reconciliation, not a claim of automatic extraction.
The outcome
One engagement, one register,
one repeatable procedure
— providing a practical baseline
for the bank's cybersecurity,
operational resilience and future
PQC migration programme.
Open to demo / RNTrust infrastructure
What we can show you today.
Everything on this slide runs on our own infrastructure — no slideware. Explore six demonstrations that turn quantum readiness into practical evidence.
Discovery demonstration
Live discovery
Scan a range you name, watch endpoints, TLS versions and hybrid key-exchange support populate the inventory.
ILLUSTRATIVE DEMO VIEW
02WEEKS
Proposed next step
Inventory pilot on one business unit
Produce a reusable cryptographic asset register and coverage methodology for the wider organisation.
Questions / Next steps
Trust is not decreed, it's built.
RNTrust — The Digital Trust Company
Dubai · Abu Dhabi · Paris · Belgrade
The road ahead
FOUR PRIORITIES
Exploring priority 01 of 04