Northwind Traders maintains one inventory record for every cryptographic use that protects a business boundary, and each record has a named system owner responsible for its migration path. The record accepts observed protocol, algorithm, certificate, library, and ownership evidence, then returns a decision-ready map of quantum-vulnerable dependencies rather than a list of certificates. The threat is harvest-now-decrypt-later collection of customer, payment, and administrative traffic protected today by public-key cryptography that a future cryptanalytically relevant quantum computer could break.
Northwind’s critical paths cross several trust boundaries. The public Storefront and mobile app reach EdgeGW; EdgeGW authenticates to Orders with mutual TLS; AuthN signs the JWTs accepted by the admin portal and APIs; PayBridge reaches a payment provider; and CI/CD signs deployable artifacts. Corporate and public certificate authorities establish separate trust roots. An auditor who finds an RSA-2048 certificate at one edge cannot yet answer whether the same primitive also signs releases, authenticates services, or validates access tokens.
The architecture makes the collection boundary visible before we assign records to it:
This diagram shows why a certificate inventory alone fails: TLS, mTLS, JWT verification, and package verification place public-key cryptography in distinct protocol roles with distinct owners.
Because the same RSA-2048 key can serve different functions, Northwind records a cryptographic use as one algorithm operating for one purpose on one boundary. A TLS server certificate, an ECDH key exchange, and a JWT signature become separate uses even when a single product exposes them. That separation matters because hybrid key establishment can reduce confidentiality exposure in a supported TLS path, while an unchanged JWT signature remains forgeable under the quantum threat model.
Each record captures the evidence needed to make a later replacement decision:
The required fields distinguish discovery from decision-making. A cipher-suite observation identifies ECDH exposure, but the library version and change path determine whether EdgeGW can adopt a hybrid implementation. A signing record needs verifier locations because changing the signer without changing the admin portal, API gateway, and deployment verifier breaks trust. The following comparison weighs the missing details that routinely stop otherwise accurate inventories from becoming roadmaps:
This table shows that algorithm discovery is necessary but insufficient: ownership, verifier reach, and product version determine whether a standardized replacement can actually be deployed.
Decision rule A record without a purpose and owner describes an artifact, not a migratable cryptographic dependency.
With the schema fixed, Northwind starts at boundaries carrying long-lived sensitive data or enforcing critical integrity decisions. client→EdgeGW captures external TLS; EdgeGW→Orders captures internal mTLS; AuthN captures JWT signing and every verifier; PayBridge captures a third-party dependency; and CI/CD captures artifact signing. The inventory must record ECDH separately from AES because AES may remain appropriate while ECDH key establishment requires replacement or a hybrid transition.
Which entry needs both a signer migration and an inventory of distributed verifiers: the AuthN JWT signing record or the EdgeGW→Orders mTLS record?
The filled inventory uses evidence-oriented records for eight Northwind findings and groups the result by RSA-2048, ECDH, and ECDSA P-256 exposure: