Algorithms & protocols
Algorithms, parameters and protocols used for encryption, signatures, hashing, authentication and key establishment.
Why it matters
Cryptography is distributed. Risk decisions need a connected view.
Cryptography can be embedded in application code, libraries, TLS endpoints, APIs, identity platforms, databases, cloud services, network appliances, HSMs, certificates, signing services and third-party products. Different teams may own each layer.
When an algorithm is deprecated or a migration becomes necessary, fragmented visibility becomes a delivery risk. Discovery should make it possible to identify affected services quickly enough to assess exposure, assign ownership and plan change.
What to discover
Capture technical facts with the context needed to act.
Keys & certificates
Purpose, owner, lifecycle state, expiry and trust relationships — never secret key material itself.
Libraries & components
Libraries, SDKs, firmware, HSMs, embedded components and products that provide or constrain cryptographic capability.
Systems & services
Applications, devices, infrastructure and business services implementing or depending on each mechanism.
Protected data
Information protected, sensitivity, required protection lifetime and relevant long-term exposure.
Ownership & suppliers
Technical owner, service owner, external provider and other parties that can implement or constrain change.
Inventory question
Not only “Where do we use RSA?” but “Which critical services depend on it, what does it protect, who owns it, and what constrains replacement?”
How to discover
Use multiple evidence sources.
Network & endpoint observationIdentify protocols, certificates, cipher suites and exposed cryptographic services.
Code & dependency analysisFind cryptographic APIs, libraries, embedded choices and software dependencies.
PKI, HSM & KMS metadataUse certificate and key-management sources without collecting secret material.
Configuration & platform dataInspect cloud, infrastructure, middleware, operating-system and appliance configurations.
Architecture, people & suppliersConnect findings to services and validate ownership, hidden dependencies and product constraints.
What good governance looks like
Discovery is a maintained capability, not a one-off scan.
A useful inventory has defined ownership, scope, refresh triggers and quality expectations. New findings are reconciled with known systems rather than accumulating as disconnected scan output.
Risk management should be able to trace a material cryptographic finding to a service, security purpose, owner and treatment path. Unknown ownership or unexplained coverage gaps should be visible as evidence gaps.
Risk lens
The target is not perfect visibility on day one. It is sufficiently reliable visibility to answer material risk and migration questions before urgency removes the organisation's options.
What to do next
Turn discovery into decision-ready evidence.
Define scopeStart with critical services, sensitive data and externally exposed or transition-sensitive technologies.
Combine sourcesAvoid relying on a single scanner, CMDB, certificate tool or questionnaire.
Add contextLink cryptographic findings to business criticality, purpose, ownership and supplier dependency.
Track uncertaintyRecord unknowns and coverage limitations rather than converting absence of evidence into false assurance.
Feed governanceUse the evidence for dependency mapping, standards compliance, risk treatment and migration planning.
Quantum readiness
PQC migration starts with visibility.
Quantum readiness requires organisations to identify quantum-vulnerable public-key cryptography and understand where replacement will be required.
Discovery is therefore migration infrastructure: without it, prioritisation and credible transition planning are largely guesswork.
Authoritative sources
Further reading
NIST NCCoEMigration to Post-Quantum CryptographyNIST NCCoEMigration to PQC FAQNIST CSRCCrypto Agility ProjectENISAPost-Quantum Cryptography Integration Study
Educational synthesis. Consult primary sources for normative and implementation-specific requirements.