Comparison · 4 min read

A control that needs the internet is a control that has outages

Security architecture normally asks what happens when a component fails. For verification paths that question is often skipped, and the honest answer is that the control stops working.

What does a verification callback actually add to your risk?

Three things you did not choose: the vendor's availability becomes your availability, the vendor's retention policy decides how long your evidence exists, and every verification tells the vendor something about your operations. None of these are visible in the architecture diagram.

Key takeaways

A callback in the verification path makes vendor availability a dependency of your control.
The callback also discloses what you are verifying, and when, to a third party — which for transaction metadata can be commercially sensitive.
Offline verification removes both, at the cost of revocation freshness, which a signed list handles adequately.

Part of Category comparisons

Three things a callback introduces

Each hop is a dependency you did not choose and cannot fix.

Dependency	Consequence
Vendor availability	Their outage becomes your outage, on your critical path
Network path	A partition, a DNS problem or a proxy change stops verification
Vendor retention	When they purge old records, your historical evidence stops verifying

The third is the one that goes unnoticed for years and then matters all at once, during an audit or a dispute about something from four years ago.

The fail-open trap

Faced with the availability problem, implementations choose. The choice is usually made implicitly, in an exception handler.

# What gets written
try:
    result = vendor.verify(receipt)
except NetworkError:
    log.warn("verification unavailable, proceeding")
    result = ALLOW              # ← the control is now optional

# What an attacker does
#   make the vendor unreachable
#   every verification passes

Nobody designs this deliberately. It arrives because the alternative — blocking business operations during a network problem — is unacceptable to whoever is on call, and the exception handler is where that pressure lands.

The metadata question

A verification call tells the vendor what you are verifying and when. Over time that is a detailed picture.

The volume and timing of your high-value approvals
Which of your staff approve what, and how often
Patterns around month end, quarter end, or a transaction
Correlation with public events — an acquisition, a filing

For many organisations this is acceptable. For some — firms handling material non-public information, organisations with sensitive counterparties, anyone in a competitive procurement — it is not, and the question is rarely raised during vendor selection.

What offline verification requires from the vendor

Less than you would expect, which is why the absence of the feature is usually a choice rather than a limitation.

Publish signing keys at a stable, well-known location.
Keep old keys published for the full retention period.
Document the canonical form so the digest is reproducible.
Publish a revocation list, signed, on a schedule.
Document the verification procedure completely enough for an independent implementation.

None of that is a service, which is exactly the point made elsewhere about business models. It is documentation and a static file.

The revocation trade, honestly

Offline verification gives up real-time revocation. That is a genuine loss and it is smaller than it appears.

	Real-time check	Signed list, published each minute
Revocation latency	Zero, if uncached	Up to one minute
Behaviour during an outage	Fails open in practice	Cached list still enforced
Privacy	Leaks the subject	Leaks nothing
Effective latency in practice	Often hours, due to caching	One minute

The fourth row is the one that settles it. Real-time checking is usually not real time, because responses are cached; a list published every minute is often fresher than what the callback actually delivers.

The architectural question to ask

For every control in your environment, one question: what happens when the network is down?

If the answer is that the control stops enforcing, it is not a control — it is a control conditional on connectivity, and an attacker who can affect connectivity can affect it.

This is not an argument against vendors or hosted services generally. It is an argument that the verification step specifically, being the point where trust is established, should not have dependencies that an adversary can influence.

A worked example: the fail-open trap

When the callback times out
Design choice	Consequence
Fail open	The control silently stops existing, exactly when something is wrong
Fail closed	Your business stops when the vendor has an incident
Cache the answer	You accept a stale decision of unknown age
Verify offline	No third choice needed — the question never leaves your network

Most deployments pick the first and do not write it down. It is the option that produces no alerts, which is precisely why it is the one that gets picked.

Objections and honest limits

“Offline verification cannot do revocation.” Honest and correct. Offline verification checks a signature and an expiry, not current status. The trade is a short validity window against a permanent network dependency — and for evidence read years later, the offline property wins outright.

“The metadata is just timing.” Timing and volume. Which of your systems verify, how often, and when the rate changes — that is a picture of your operations, delivered continuously to a third party.

Questions for any verification vendor

Can I verify with no network call? If no, the rest follows from that.
What happens when your service is unavailable? And is fail-open the default.
What do you see when I verify? Volume and timing are also data.
How long do you retain the records? Shorter than your evidence needs, usually.
Can I verify after we stop being a customer? The answer is often no.

Terms used here

Callback verification: Checking validity by calling the issuing vendor, making their availability part of your control.
Fail open: Allowing an action when a control cannot be evaluated — usually the silent default.
Offline verification: Checking a signature against a published key set with no network call to the issuer.

Frequently asked questions

Why do implementations fail open? Because blocking business operations during a network problem is unacceptable to whoever is on call. The decision gets made implicitly in an exception handler.

What does a verification callback disclose? What you are verifying and when. Over time that reveals approval volumes, timing patterns and which staff approve what.

Doesn't offline verification lose real-time revocation? It trades it for a publication interval. Real-time checks are usually cached for hours anyway, so a list published each minute is often fresher in practice.

What does a vendor need to provide? Published keys retained for the retention period, a documented canonical form, a signed revocation list and a complete verification procedure. Documentation and static files.

Is a callback always wrong? No. For short-lived, revocation-sensitive decisions it is reasonable. For evidence read years later it is a dependency that will outlive the vendor.

What is the honest cost of offline verification? No live revocation. You manage it with short validity windows and re-issuance instead.

What should I ask a vendor first? Whether verification works with the network unplugged. Everything else follows from that answer.

Where this fits in Manav

Manav verifies offline against a published JWKS — no callback, no availability dependency, and nothing reported back to us.

See offline verification →

Sources and further reading

RFC 6960 — Online Certificate Status Protocol
RFC 7517 — JSON Web Key
Published guidance on availability dependencies in security architecture.
NIST SP 800-53 Rev. 5 — Security and Privacy Controls