tech · quantum risk

COBOL Language: What It Is and Why Banks Still Run It

Risk: varies · Confidence: high · Reviewed: 2026-07-19

Verdict

COBOL as a language is not “broken by Shor.” Quantum risk for COBOL estates is almost always inherited from classical public-key cryptography in surrounding channels: TLS, certificates, HSMs, APIs, and partner links.

Overview

COBOL (Common Business-Oriented Language) remains embedded in large financial institutions because it powers reliable batch processing, account ledgers, and decades of certified operational procedures. That longevity is a feature for stability—and a constraint for cryptographic migration.

Quantum computing does not “attack COBOL grammar.” Shor’s algorithm targets public-key schemes (RSA, ECC, finite-field Diffie–Hellman) used in authentication and key exchange. Those schemes usually live in TLS terminators, certificate authorities, HSMs, payment switches, and API gateways that COBOL jobs call or are called through.

This page orients engineers and risk teams: what COBOL is, why it persists, and where quantum-relevant cryptography actually sits. Deep banking process context is under /tech/cobol/banking; the direct “is COBOL quantum proof?” answer is at /is-quantum-proof/cobol.

Cryptographic profile

Signatures: Not inherent to COBOL — depends on called libraries, middleware, and OS crypto
Hash: Application-defined; often delegated to enterprise security modules
Public-key exposure: COBOL programs typically do not implement secp256k1/RSA themselves; they call CICS, MQ, DB2, HSMs, or network stacks that terminate classical TLS/PKI.

Longevity of COBOL estates is a migration constraint: slow change windows, batch calendars, and certified platforms.
Inventory “where crypto happens” at the edges of COBOL systems, not only source lines of code.

What breaks

Assuming COBOL source itself is the cryptographic vulnerability
Ignoring TLS/PKI on channels that feed batch and online COBOL services
Leaving decade-lived certificates and static keys on middleware uninventoried

Mitigations

Map every external interface: MQ, file transfer, APIs, 3270/web gateways, partner VPNs
Treat crypto inventory as middleware + HSM + network, not “rewrite COBOL first”
Align core-banking change windows with hybrid TLS and certificate agility programs
Read the banking-specific and is-quantum-proof/cobol pages next

FAQ

Is COBOL outdated and therefore quantum-broken?

Age of the language is not the same as quantum vulnerability. Classical public-key algorithms on the network and key hierarchy are the usual issue—whether the business logic is COBOL, Java, or something else.

Do we need post-quantum COBOL compilers?

Unlikely as the first step. You need crypto-agile libraries, HSM support, certificate profiles, and hybrid TLS on the paths that protect data and identity. Application language is secondary.

Where should a bank start?

Cryptographic inventory of channels and keys around core systems, then pilot hybrid TLS and certificate lifecycle—parallel to COBOL modernization programs, not blocked by them.

Key concepts (technical dictionary)

Terms used on this page — open a definition:

Full technical dictionary →