A verification service that does not respond has not proved the application untrustworthy. A failure policy defines which operations can continue under uncertainty.
Evaluation approach
Separate low-risk reads from high-risk changes. If access remains open, limits may apply to time, transaction value or additional verification.
Application example
The balance screen might display cached information while adding a new recipient is postponed. Giving the user a way to retry matters alongside security.
Limits and considerations
One global decision may not suit the whole application. Examine whether attackers could deliberately trigger the outage path to exploit the policy.
Avoid one rule for every unknown
A control-service timeout differs from clear evidence of interference. One means information is unavailable; the other means a specific risk was observed. Applying the same automatic response can turn an availability problem into a larger security incident.
Policies may differ by operation: general content remains available while new value transfers wait. Whether that is acceptable depends on loss and continuity requirements. Include when a pending operation expires and how the user is informed.
Checks and decisions
- Distinguish failure types
- Define transaction classes
- Exercise outage scenarios
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.