You Can't Migrate What You Can't See

Every Milestone 1 obligation in the DST report — complete discovery and inventory of cryptographic artefacts, conduct quantum risk analysis, prioritise assets, produce a CBOM — depends on one prior act that the report lists first for a reason: finding the cryptography in the first place. It sounds trivial. It is the single most underestimated task in the programme.

Why organisations don't know their own cryptography

Cryptography is not a system you can point to. It is a property scattered across thousands of places, accumulated over decades by people who have long since moved on. In a typical bank it hides in:

• TLS configurations on load balancers, gateways and services — each with its own cipher suites and certificate.
• Dependency trees — an application calls a library, which calls another, which quietly uses RSA. The crypto is real; it appears in no architecture diagram.
• Legacy systems running cryptographic code no current employee has read, sometimes on platforms that are themselves out of support.
• Certificates and keys issued by teams that have reorganised, stored in places the security team doesn't control, expiring on calendars no one watches.
• HSMs, KMS and firmware — the root-of-trust layer, where a single RSA key may underwrite thousands of downstream operations.
• Vendor and third-party systems whose internal cryptography the bank cannot see at all without asking — which is exactly why the report pushes CBOM into procurement.

The crypto you've documented is the tip. The crypto that breaks your migration plan is the part you've never charted.

The four ways into a bank's estate

Discovery in BFSI is not one technique; it is several, because no single method sees everything — and because Indian regulated banks rightly refuse to expose internal systems carelessly. In practice, four distinct access categories are each negotiated separately, often with different teams:

• Network scanning across internal CIDR ranges to find live TLS endpoints, their protocols and certificates.
• Credentialed connectors that read configuration from systems directly, catching crypto that isn't exposed on the wire.
• File-system and codebase scanning to find library usage, hardcoded keys and certificate stores.
• Direct upload of configs, certificates and inventories the bank already holds.

The deployment reality follows from this: because banks will not hand external parties open access, most discovery runs as a vendor-deployed appliance inside the data centre or as a customer-run scanner whose output is shared — not as an external service reaching in.

Why a partial map is dangerous, not merely incomplete

An incomplete inventory does worse than leave gaps — it manufactures false confidence. A bank that has catalogued its main TLS certificates and headline applications can produce a tidy CBOM, report progress to its board, and still be wide open through a legacy reconciliation job that signs with RSA-1024 and talks to the internet. Under the report's assume-breach principle, the asset you didn't find is the asset already being harvested. Discovery is where the programme's honesty is established or lost.

Discovery is continuous, not a one-time scan

A final misconception worth retiring: discovery is not a project that finishes. New systems are deployed, certificates are issued, vendors change their internals. The report's later milestones assume an authoritative, living register of cryptographic assets and vendor algorithm usage — maintained, not snapshotted. The first scan is the hardest because it surfaces decades of accumulation; keeping the map current afterward is the discipline that makes crypto-agility (N° 09) possible at all.