Android and iOS

Caching attestation results

Designing client, server, framework and policy layers together.

Protection architecture1 min readEditorial methods

A cached integrity result may no longer represent the environment at transaction time. Choose validity periods and reassessment triggers according to the operation's risk.

Evaluation approach

Define the result's valid operation scope and lifetime. Platform-recommended request patterns differ from an application's own result cache.

Application example

Do not automatically reuse a clean sign-in result for a new-recipient transaction hours later. Sensitive steps may require fresh evaluation.

Limits and considerations

Caching does not prove that the environment stayed unchanged after the check.

How much staleness is acceptable?

Caching can reduce delay while postponing detection of changed risk. Cache keys must correctly represent account, application and evidence scope. One user's result must not carry into another session.

Set freshness requirements for sensitive actions and invalidation rules for expiry, session revocation and policy changes. Report performance gains together with the accepted age of evidence.

Checks and decisions

  • Document validity scope
  • Separate sensitive operations
  • Reject stale results

Improve request patterns and timing before reducing latency by silently weakening trust binding.

Sources

The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.