A device check can return a reassuring result while the application still makes the wrong access decision. The missing step is policy: what does that result permit, for whom and for how long? Detecting a condition and enforcing a boundary are separate pieces of work.
A signal needs a consumer
Google’s Play Integrity API overview describes verdicts about the app, its installation context and the device environment. A backend can use those signals when responding to requests. Google recommends combining the API with other signals rather than using it as the sole anti-abuse mechanism.
This is a concrete example of an integrity service, not a statement that UseCrypt integrates it. A product’s actual implementation needs its own documentation. The general design question is what the receiving system does after a verdict arrives.
Name the operation that needs approval
Consider a hypothetical document application that requests an integrity verdict at sign-in. The user later asks to export a sensitive file. Has the application decided that the original check covers the export too? Is the result bound to that particular request, or has an earlier success become a reusable permission?
Those questions do not imply that any identified product has a flaw. They define what a review would need to establish. An interface saying that a device passed a check is not evidence that every later operation evaluated an appropriate result. Likewise, an operation being refused does not reveal which signal caused the refusal.
Time is part of the policy. An application should have an explicit answer for a missing, delayed or unusable result. A retry may be appropriate for a temporary service problem. It should not silently turn a request that requires approval into one that always succeeds.
A warning and a refusal are different outcomes
A historical source can explain why the issue matters without settling today’s implementation. AVLab’s December 2019 messenger comparison included starting a messenger on a rooted or jailbroken device among its scenarios and described UseCrypt’s device-protection features. That dated account is not evidence of a current API integration, a contemporary test result or universal detection.
For a deployment review, distinguish an informational warning from a policy that denies an operation. Both may have legitimate uses. The requirement should say whether a person can acknowledge the warning and continue, whether an administrator can approve an exception and whether that exception is visible in the record.
Test the decision, not just the badge
Use a test account and synthetic material in an authorised environment. Write down the sensitive action before running it. Observe a permitted case, a denied case and the case where the required signal cannot be obtained. Do not weaken a production device or bypass another system’s protections to create a demonstration.
Record the application version and the observation point. If the evaluator sees only the client, they may not know whether a backend independently verified the result. That is an evidence limit, not permission to invent the server behaviour. A fuller review can request the relevant server-side record through the system owner’s approved process.
The existing Messenger explanation of local records and keys belongs in the same knowledge base, but it answers a different question. Good documentation connects those boundaries without merging their claims. The final acceptance criterion is an observed, correctly authorised operation, not the presence of a security badge.
