Runtime integrity concerns changes to application behavior after launch. A startup result may not provide the same assurance throughout the session.
Evaluation approach
Assess loaded code, function behavior and critical data flows within the product's coverage. Startup checks and checks near a transaction observe different time windows.
Application example
After sign-in, measure the age of the integrity result used during a critical approval flow.
Limits and considerations
File-signature checks alone cannot explain every form of in-memory interference.
The state after startup
The condition observed at launch may differ from that during a sensitive operation. Ask how frequently runtime checks run, which modules they cover and how result age is tracked. Continuous protection is not, by itself, a test definition.
If checks exclude extensions or components loaded later, state that boundary in the report. Assess latency, battery and crash impact on real devices. Protection effectiveness and application usability belong in the same release decision.
Checks and decisions
- Separate code and data flows
- Record check timing
- Verify server decisions
Test the check near the critical operation together with server enforcement.
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.