A certificate record can tell you what exists. Assurance must determine what the certificate protects, how the service behaves, whether the trust decision is sound, what would be affected by failure and whether a change has reached every expected usage. That requires correlation, not another expiry dashboard.
01 · Inventory is the beginning
An expiry date does not describe the service at risk.
Subject, issuer, serial number, validity period and fingerprint identify a certificate version. They do not show which endpoint presents it, which infrastructure resource terminates the connection, whether the hostname is covered, whether the chain is trusted or what operational consequence follows if the certificate fails.
The distinction matters because certificate objects and certificate usages are not the same thing. One certificate may be presented by many services. One service may present different versions across regions or listeners. A certificate near expiry may be unused, while the certificate protecting a critical production endpoint may not appear in a manually maintained inventory at all.
Inventory answers what exists. Usage assurance answers what is active, trusted, exposed, owned and verified.
02 · Evaluate the connection
Observe the service, not only the certificate object.
Statepoint evaluates the live TLS presentation in the context of the requested service. The observation begins with the hostname, SNI, address, port and protocol. It records the certificate and chain returned by that connection, then evaluates identity, validity, cryptographic posture and trust as separate dimensions.
Private keys and secret values are not required for this analysis. The useful evidence is the public certificate material, the observed service behaviour and the infrastructure relationships that explain its use.
These parameters prevent a broad label such as SSL issue from hiding the actual condition. An expired certificate, a hostname mismatch, an incomplete chain and support for an obsolete protocol are different facts. They require different explanations, owners and remediation paths.
03 · Evidence ingestion
The backend preserves the facts needed to reproduce the decision.
Evaluated parameters are ingested as evidence with their source, scan or observation identifier, collection time and confidence. Certificate identity is anchored to the leaf fingerprint rather than a display name. Endpoint identity retains the hostname, address, port and service context in which the certificate was observed.
Infrastructure inventory adds the surrounding resource context. Where the evidence supports it, the observation is connected to the account or subscription, region, environment, load balancer, gateway, listener, certificate store and backing workload. This keeps observed data separate from declared ownership or expected configuration while allowing both to contribute to the eventual decision.
What the endpoint and connected platforms reported at a specific time.
Expected usage, criticality, ownership and renewal responsibility.
Trust, exposure, lifecycle and priority conclusions produced from evidence.
04 · Assurance correlation
A certificate becomes meaningful through its relationships.
The Assurance layer does not evaluate each field in isolation. It connects the certificate version to the endpoint where it was seen, the resource serving that endpoint, the exposure path, the applicable policy, the responsible owner and the previous observations that establish change.
Each conclusion remains linked to the evidence and relationship path that produced it, so a team can inspect why the condition applies.
This is also how Statepoint distinguishes a current deployment from stale history. First seen, last seen, observation freshness and fingerprint changes reveal whether a certificate remains active, has been replaced or is still presented by only part of a distributed service.
05 · Threat and consequence
Severity comes from the condition and its operating context.
The Assurance layer evaluates concrete failure and threat conditions: expiry or premature validity, hostname mismatch, untrusted or incomplete chains, weak keys or signatures, deprecated protocol support, unexpected certificate changes and inconsistent deployment across related usages.
It then correlates those conditions with exposure and consequence. A weak TLS configuration on an isolated development service is not the same decision as a trust failure on a publicly reachable production gateway. Internet reachability, service criticality, environment, affected usages, evidence confidence and ownership all influence priority and response.
Do not turn one failed parameter into an unexplained risk label. Preserve the observed condition, the connected context and the reasoning that converts both into a prioritised action.
06 · Lifecycle assurance
Renewal is a deployment process, not a calendar event.
A useful record identifies the service owner, environment, criticality, renewal method, notification path and expected replacement. The response window should reflect the certificate's actual lifetime and the time required to issue, review, deploy and, if necessary, roll back the change.
History adds the evidence needed to detect operational failure. If a new fingerprint appears on one listener while the old version remains active elsewhere, the important condition is partial rotation. If the expected replacement exists in a certificate store but is not presented by the service, issuance has occurred but deployment has not completed.
07 · Outcome verification
Close the action with a fresh observation.
Remediation is complete only when current evidence confirms the intended certificate is active at every expected usage and the original trust or cryptographic condition no longer applies. A fresh connection should verify the fingerprint, hostname, chain, validity and protocol posture, while the resource relationship confirms where the change took effect.
Statepoint keeps that reassessment connected to the original observation, the prioritised decision, the accountable owner and the implemented change. The result is more than an inventory update. It is a defensible record of what was observed, how the threat was evaluated, what action was taken and how the outcome was proven.
Observe the service. Ingest the evidence. Correlate certificate, infrastructure and ownership context. Evaluate threat and consequence. Act, then verify the result with current evidence.