What breaks when cryptography is only tracked in spreadsheets?

Manual tracking leaves ownership, dependency mapping and renewal state too incomplete for migration planning. It also makes prioritisation unreliable, because teams cannot confidently distinguish high-risk cryptography from lower-risk systems or verify whether a change will affect a hidden dependency.

Why This Matters for Security Teams

Spreadsheet-based cryptography tracking usually fails because it records names, not operational reality. Teams can list certificates, keys, algorithms, and owners, but they still miss renewal dependencies, certificate chaining, environment scope, and where cryptography is embedded in code or CI/CD. That gap turns migration planning into guesswork and makes prioritisation unreliable.

This matters because cryptography is not just an inventory problem. It is a change-management problem, a dependency problem, and a service continuity problem. When a weak algorithm needs replacement, the real risk is often not the algorithm itself but the hidden systems that will break when it is rotated, reissued, or deprecated. NHI Mgmt Group notes that the Ultimate Guide to NHIs shows how incomplete visibility remains a core failure mode across NHI estates, and that same pattern applies to cryptographic assets stored in spreadsheets.

Standards bodies expect traceability and ongoing control, not static recordkeeping. The control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls and PCI DSS v4.0 both assume security teams can locate, manage, and verify cryptographic material throughout its lifecycle. In practice, many security teams discover broken renewals and undocumented dependencies only after a migration window has already closed.

How It Works in Practice

A usable cryptography inventory needs to answer operational questions, not just catalog objects. For each key, certificate, or algorithm, teams should know who owns it, where it is used, what depends on it, when it expires, whether it is externally trusted, and whether it supports a legacy migration path. Spreadsheet fields rarely stay current enough to support those decisions, especially in fast-moving environments.

Current best practice is to treat cryptographic tracking as a living control, ideally fed by discovery tooling, configuration management, certificate managers, and pipeline scans. That approach makes it possible to map assets to services, environments, and renewal workflows. It also helps identify high-risk items such as long-lived keys, externally exposed certificates, and cryptography embedded in build systems or application code. The broader NHI governance guidance in the Ultimate Guide to NHIs is relevant here because the same visibility and lifecycle discipline applies to non-human credentials and secrets.

• Track owner, system, environment, algorithm, expiry, and dependency links for every item.
• Separate discovery from approval so the inventory can be validated against live infrastructure.
• Flag hidden dependencies in code, containers, CI/CD, and partner integrations.
• Use renewal workflows that notify owners early enough to test migration safely.
• Require evidence that replacement cryptography is actually in use before decommissioning the old material.

Security teams should also align the inventory to policy requirements in NIST SP 800-53 Rev 5 Security and Privacy Controls rather than treating it as an administrative spreadsheet exercise. These controls tend to break down when cryptography is embedded in unmanaged third-party applications because ownership and dependency evidence is usually incomplete.

Common Variations and Edge Cases

Tighter cryptography tracking often increases operational overhead, requiring organisations to balance better visibility against the cost of maintaining accurate dependency data. That tradeoff becomes more pronounced during cloud migration, M&A activity, or when legacy systems still rely on obsolete protocols and certificates.

There is no universal standard for spreadsheet-based cryptography governance, and current guidance suggests moving to system-backed inventory as soon as cryptographic change becomes business critical. Small environments may tolerate a spreadsheet temporarily, but only if the data is reconciled against live systems and tied to owners with explicit renewal accountability. Even then, the model is fragile.

Edge cases matter. A certificate that looks low risk may actually protect a customer-facing API, a signing process, or a service mesh trust chain. Likewise, a key that appears dormant may still be required by a batch job, a vendor integration, or an archived workload. For organisations with broad third-party exposure, NHIMG’s Ultimate Guide to NHIs is a useful reminder that hidden dependencies and incomplete ownership are persistent control failures, not rare exceptions.

Related resources from NHI Mgmt Group

• What breaks when mitigation controls are only tracked in spreadsheets?
• What breaks when HIPAA evidence is tracked in spreadsheets?
• What breaks when digital identity design focuses only on convenience?
• What breaks when CIP is treated as a compliance-only exercise?