Every cryptographic discovery method in common use today shares a blind spot, and it is the same blind spot: none of them sees what a running process actually does with cryptography in memory. Static analysis reads the declared cryptography in source, binaries, and configuration, the crypto an artifact says it contains. Active probing observes the negotiated cryptography on a reachable endpoint, the crypto a system agrees to over the wire. Both are real and both are valuable, and between them they miss the layer where cryptography is actually exercised, which is the code path a live process takes when it loads a library, calls a crypto function, and chooses an algorithm at the moment of execution. That layer is the deepest frontier of discovery, and it is where the field is heading rather than where it has arrived.
Runtime cryptographic observation is the idea of watching cryptography as it executes, below the application layer, by instrumenting the process or the kernel rather than reading artifacts or probing ports. The appeal is straightforward once the gap is named: a system can declare one thing in its configuration, negotiate another on the wire, and invoke a third in memory because of a code path that only runs under specific conditions, and only runtime observation would catch that third case. The difficulty is equally real, which is why this is best understood as a direction the strongest discovery approaches are moving toward rather than a settled, shipped capability. This post is written in that spirit, as a map of where deep discovery is going and why, not as a claim about a finished product.
The Certificate Visibility Gap
Typical enterprise: what's tracked vs. what actually exists
Tracking Coverage
Certificates Found by Source
⚠️ In the average mid-market enterprise, less than 15% of certificates have both ownership documentation and expiry monitoring.
The Three Layers of What Crypto Is
To see why runtime observation is a distinct frontier, it helps to separate three different things that all get called an asset’s cryptography, because the methods that see each one are different and the gaps between them are where risk hides.
| Layer | What It Is | What Sees It |
|---|---|---|
| Declared | Crypto written in code, binaries, and config | Static analysis |
| Negotiated | Crypto a live endpoint agrees to on the wire | Active probing |
| Invoked | Crypto a running process actually loads and calls | Runtime observation |
Declared cryptography is what an artifact states it contains: the algorithm named in source, the cipher suite listed in a config file, the library linked into a binary. Static analysis reads this well, and it is the broadest view of what an estate could use. Negotiated cryptography is what a system actually agrees to when a peer connects: the TLS version and cipher a server selects, the certificate it presents. Active probing captures this, and it is ground truth about behavior on reachable ports.
Invoked cryptography is the third thing, and it is neither of the first two. It is what a process actually loads into memory and calls at runtime, which can differ from both the declared and the negotiated view. A binary may link three crypto libraries and invoke only one. A configuration may permit an algorithm the running code never selects, or the code may fall back to an algorithm the configuration did not obviously declare. The invoked layer is the truth of what the software does, as opposed to what it says it does or what it agrees to do, and no amount of static reading or endpoint probing reaches it directly. That is the gap runtime observation exists to close.
What Runtime Observation Would See
The reason the invoked layer matters is that it catches cryptography the other two layers structurally cannot, and the examples are the kind that cause the worst surprises in a migration or an incident.
Consider dormant or conditionally loaded cryptography: a library or algorithm that is present but only invoked under a condition that a scan did not trigger, a legacy fallback, an error path, a feature flag. Static analysis sees that the library is linked and cannot tell you whether it is ever called. Active probing never triggers the condition and so never negotiates it. Runtime observation, watching the process as it runs through its real workloads, would see the invocation when it happens and record that the algorithm is not merely present but actually exercised, which is the difference between a theoretical risk and a live one.
Consider dynamically configured cryptography, where the algorithm or key in use is selected at runtime from a source a static scan cannot resolve, an environment variable, a remote configuration service, a value computed at startup. The declared view shows a variable, not a value; the negotiated view might show one outcome on one probe and miss the range of others. Runtime observation would see the actual value the process resolved and used. Consider protocol-downgrade behavior in a live process, where a client or server falls back to a weaker protocol under conditions that a single probe would not reproduce but that occur in production; observing the running process over time would catch the downgrade as it actually happens. In each case the common thread is that the truth is in the execution, and the execution is exactly what runtime observation is positioned to see and the other methods are not.
Why It Is Hard
If runtime observation sees the most, the obvious question is why it is the frontier rather than the default, and the answer is that doing it well is genuinely difficult along several dimensions at once. These are not reasons to dismiss the approach; they are the reasons it is a direction of travel rather than a solved problem, and being candid about them is part of describing the frontier honestly.
The first difficulty is performance. Observing cryptographic operations as a process executes means instrumenting hot code paths, and instrumentation that adds meaningful latency or overhead to production cryptography is instrumentation that will be switched off. Any runtime approach has to impose a cost low enough that an operator will tolerate it on real workloads, which is a demanding constraint when the thing being observed runs at the core of the system’s performance.
The second is access. Seeing invoked cryptography in memory often requires privileged vantage points, in-process instrumentation that must be integrated into the application, or kernel-level mechanisms such as eBPF that observe from below the process. eBPF is attractive precisely because it can watch system and library behavior from the kernel with relatively low overhead and without modifying the application, but it requires the access and the operational acceptance that kernel-level observation implies, which is not available in every environment. The third difficulty is coverage: runtime observation only sees processes that are actually running and actually exercising their crypto during the observation window, so it shares, in a different form, the point-in-time limitation of active probing. A process that runs a crypto path once a quarter is a path the observer has to be present for. Together these make runtime observation powerful in principle and demanding in practice, which is exactly the profile of a frontier.
Where the Category Is Heading
The honest framing is that runtime observation represents the direction deep discovery is moving, not a box that is checked. The trajectory is clear enough to describe even though the destination is not fully reached. Discovery began with endpoint probing because the network was the reachable surface. It deepened into static analysis because so much cryptography lives in artifacts that are never probed. The next deepening is into the runtime, because the gap between what software declares, what it negotiates, and what it invokes is real and consequential, and closing it is the logical continuation of the same drive toward completeness that produced the earlier modes.
What the strongest discovery approaches are moving toward is a layered model in which static analysis establishes the declared picture, active probing confirms the negotiated behavior, and runtime observation, as it matures, fills in the invoked truth, with each layer reconciled against the others so that the discrepancies between them become signal rather than noise. A disagreement between the declared and the invoked view is not an error; it is a finding, the place where what the software says and what it does diverge, which is precisely where dormant and dynamically configured crypto hides. A platform that can eventually surface those discrepancies will see cryptography that today’s methods leave invisible.
The reason to treat this as thought leadership rather than a feature claim is that credibility in this field rests on not overstating reach. Runtime observation is the frontier, and a platform worth trusting is clear about the difference between the discovery it performs today and the depth the category is still growing into. The right posture for a buyer is to understand this layer as where discovery is heading, to ask any vendor to be precise about which layers they reach now, and to value candor about the invoked layer over a premature claim to have conquered it. That candor is itself a signal of a platform that understands the problem.
Why This Frontier Matters Now
It is fair to ask why a layer that is still emerging deserves attention today, and the answer is the post-quantum migration. Migration requires knowing what cryptography an estate actually uses, not merely what it declares, because the assets that will cause the worst surprises during a transition are the ones that are present but invisible, the dormant fallback that activates under load, the dynamically configured algorithm that resolves to something the plan did not account for, the downgrade path that quietly reintroduces a protocol the migration was supposed to retire. Those are invoked-layer phenomena, and a migration planned only on the declared and negotiated views carries a blind spot into the one project where blind spots are most expensive.
So the frontier matters now even though it is not finished, because understanding that the invoked layer exists changes how an organization reasons about completeness. An inventory that is confident on the declared and negotiated layers and silent on the invoked one is not complete; it is complete up to a boundary that the strongest approaches are working to push back. Knowing where that boundary sits, and watching the category move it, is how a serious program plans a migration that will not be surprised by the cryptography its tools could not yet see.
FAQ
Q: What is runtime cryptographic observation? It is the idea of watching cryptography as a process executes, observing the libraries it actually loads, the crypto functions it actually calls, and the algorithms it actually selects in memory, rather than reading artifacts or probing ports. It targets the invoked layer of cryptography, which differs from the declared layer that static analysis reads and the negotiated layer that active probing sees. It is best understood as the frontier deep discovery is heading toward, not a settled capability.
Q: How is the invoked layer different from declared and negotiated crypto? Declared crypto is what an artifact states it contains, read by static analysis. Negotiated crypto is what a live endpoint agrees to on the wire, seen by active probing. Invoked crypto is what a running process actually loads and calls, which can differ from both, a binary may link several libraries and call one, or a config may permit an algorithm the code never selects. The invoked layer is the truth of what software does rather than what it says or agrees to.
Q: What would runtime observation catch that other methods miss? Dormant or conditionally loaded cryptography that is present but only invoked under a condition a scan did not trigger; dynamically configured cryptography whose algorithm or key is resolved at runtime from a source a static scan cannot see; and protocol-downgrade behavior that occurs in a live process under conditions a single probe would not reproduce. The common thread is that the truth is in the execution, which is what runtime observation is positioned to see.
Q: Why is runtime observation hard? Performance, because instrumenting hot cryptographic code paths risks overhead an operator will not tolerate on production workloads; access, because seeing invoked crypto often needs in-process instrumentation or kernel-level mechanisms such as eBPF and the operational acceptance those imply; and coverage, because it only sees processes actually running and exercising their crypto during the observation window. These make it powerful in principle and demanding in practice, which is why it is a direction of travel.
Q: If it is still emerging, why does it matter now? Because post-quantum migration requires knowing what cryptography an estate actually uses, not just what it declares, and the assets most likely to cause surprises during a transition, dormant fallbacks, dynamically resolved algorithms, quiet downgrade paths, live at the invoked layer. Understanding that this layer exists changes how a program reasons about completeness and keeps a migration from carrying an invisible blind spot into the project where it is most expensive.
About QCecuring
QCecuring treats runtime cryptographic observation, seeing the libraries a process actually loads, the crypto calls it actually invokes, and downgrade behavior in live processes, as the deep-discovery frontier the category is moving toward, reachable through in-process instrumentation and kernel-level techniques such as eBPF. Observing cryptography at the invoked layer, reconciled against the declared and negotiated views, is an area QCecuring is developing, and the direction it sees deep discovery heading rather than a shipped capability to overstate today.
Talk to us about where deep cryptographic discovery is heading
Tags: CBOM, Cryptographic Inventory, Runtime Observation, eBPF, Crypto Discovery, Static Analysis, Dynamic Analysis, Post-Quantum Cryptography, Kernel Instrumentation, Shadow Cryptography, Protocol Downgrade, Enterprise Security