Basic Integrity is a device attestation result that indicates whether a mobile device passes a minimal integrity check. It is a weaker signal than full device certification checks and is often used to flag obvious tampering, such as a modified system image, before the app trusts the device.
What Basic Integrity Checks Tell You
Basic Integrity is a coarse attestation signal, not a full trust decision. It usually answers a narrow question: does the device still look unmodified at a basic level, or are there obvious signs of tampering that should block higher-trust actions?
Because the check is intentionally lightweight, it is best understood as a minimum bar. A pass can support access decisions, but it does not prove the device is fully secure, uncompromised, or compliant with every policy requirement.
Why Basic Integrity Is Weaker Than Full Certification
The main value of Basic Integrity is speed and broad coverage. It can quickly screen out devices with obvious modification, such as a rooted or otherwise altered system state, before the application relies on them for sensitive operations.
Its weakness is also its purpose: it is easier to satisfy than stronger certification-style checks. That means a device may clear Basic Integrity while still carrying meaningful risk, especially if the attacker can hide changes, manipulate the environment, or operate below the threshold that the check detects.
For that reason, Basic Integrity should be treated as a signal in a layered trust model, not as proof of device safety. The stronger the action, the more support you need from additional checks, policy, and runtime controls.
How Organisations Should Use the Signal
Basic Integrity is most useful as part of a decision tree. Teams often use it to gate low-risk access, step up authentication, or block actions when a device fails the minimum integrity bar.
It should be paired with device inventory, policy evaluation, and environment awareness. A pass or fail means little if the organisation cannot tell which devices are in scope, which ones are internet-exposed, and which workflows depend on them.
Where the business impact is high, organisations should avoid using Basic Integrity alone as the only trust control. It is better suited to early filtering than to final authorisation for privileged or sensitive activity.
What a Failed or Passed Check Means Operationally
A failed Basic Integrity result usually indicates an obvious trust problem, but it does not identify the full attack path. A pass, by contrast, only says the device did not fail the minimal check at that moment.
That distinction matters after suspected compromise. If a device was used during a suspicious session, teams should review the session, connected accounts, and any secrets, tokens, or keys that may have been exposed while the device still appeared trustworthy. The relevant vendor guidance and attestation documentation should be the source of truth for what the result does and does not guarantee.
Risk and Threat Considerations
Basic Integrity can create false confidence if teams treat a minimal attestation result as strong evidence of safety. Attackers benefit when defenders rely on a weak signal to grant access, because the device may still be compromised in ways the check does not detect.
Failure mechanism: A modified or controlled device can pass a minimal integrity test if the tampering stays below the detection threshold, or if the attacker preserves enough normal-looking behaviour to satisfy the attestation path.
Impact: The organisation may grant access to a device that can observe sessions, steal credentials, intercept sensitive data, or participate in further abuse even though it appeared trustworthy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-63 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Device integrity gates user authentication and trust decisions before access is granted. |
| IA-5 — Authenticator Management | Integrity failures can require credential or token rotation after suspected compromise. | |
| SI-7 — Software, Firmware, and Information Integrity | Basic Integrity is an integrity-checking signal aimed at detecting obvious device tampering. | |
| Recommendation — Bind access decisions to authenticated users and require stronger checks when device trust is weak. Rotate compromised authenticators and remove exposed secrets after a failed or suspicious attestation. Use integrity controls to detect tampering and block trust when device state is suspect. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Device trust signals can support higher-assurance identity decisions when paired with authentication policy. |
| Recommendation — Use stronger assurance requirements for sensitive access when device integrity is weak. | ||
| SLSA | L3 — Provenance and tamper resistance | The term reflects a trust check that tries to separate trustworthy from tampered environments. |
| Recommendation — Require higher provenance and tamper resistance where device trust must be stronger than a basic check. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Weak device trust can accompany insecure deployment and control-plane conditions that undermine integrity assumptions. |
| NHI-05 — Overprivileged NHI | When device trust is weak, excessive privilege becomes more dangerous because abuse is easier after compromise. | |
| Recommendation — Treat weak environment integrity as a reason to tighten deployment and trust controls. Reduce privilege on devices or sessions that only meet minimal integrity requirements. | ||
| MITRE ATT&CK | T1211 — Exploitation for Defense Evasion | Tampering and integrity bypass are often used to keep compromised devices looking normal. |
| Recommendation — Hunt for tampering and stealthy changes when integrity results do not match observed behaviour. | ||
Practitioner Guidance
Why practitioners should care: Use Basic Integrity as an early trust filter, not as the final basis for high-value access. Its operational value is strongest when it is one input to a broader device posture decision.
What to watch for: Treat repeated failures, sudden changes in device state, or mismatches between attestation results and observed behaviour as investigation triggers. If a device passes Basic Integrity but still behaves suspiciously, assume the signal is incomplete.
Practitioner takeaway: The safest pattern is to pair Basic Integrity with stronger attestation, step-up controls, and post-event review rather than letting a minimal pass become a blanket trust decision.
Related resources from NHI Mgmt Group
- Why do file integrity tools miss attacks like Copy Fail?
- What is the difference between code integrity risk and identity exposure risk in CI/CD?
- What is the difference between basic identity management and identity maturity?
- How should security teams choose between basic, predefined, and custom GCP IAM roles?