Hardware attestation checks platform-backed device signals such as TEE-backed integrity evidence, while software attestation checks the running app instance, often by analysing live memory and code state. Hardware evidence is useful but easier to fragment across ecosystems. Software attestation helps close the gap when the device signal is spoofed or unavailable.
How hardware attestation differs from software attestation
Hardware attestation is anchored in platform trust, so the verifier relies on signals produced by device components such as a secure enclave or TEE. That makes it stronger when you need evidence the device itself is in a known state, but it also depends on ecosystem support and can vary by platform. software attestation instead checks the live app instance and its execution state, which makes it more portable but also more sensitive to runtime manipulation.
The practical difference is the trust boundary. Hardware attestation asks, “Can I trust this device substrate and its reported state?” Software attestation asks, “Can I trust this app process right now?” In mobile security, that distinction matters because an app can be genuine while the device is compromised, or the device can look healthy while the app has been hooked, instrumented, or otherwise altered in memory.
Why mobile teams use both checks together
Hardware evidence is useful for coarse assurance, especially when the platform can prove integrity from boot or hardware-backed state. Software attestation fills the gap where the device signal is unavailable, fragmented, or too easy to spoof across different ecosystems. That is why mobile assurance programs usually treat them as complementary controls rather than substitutes.
In practice, hardware attestation is better suited to device posture decisions such as whether to allow enrollment, privileged access, or access to sensitive functions. Software attestation is better suited to runtime decisions, such as whether to trust the current app session, whether the app appears tampered with, or whether the process state matches the expected build and execution path.
Both checks have limits. Hardware attestation can tell you less about what the app is doing after launch, and software attestation can be stronger against runtime tampering but weaker if the attacker controls the operating environment. The useful question is not which one is “better” in the abstract, but which trust problem you are trying to prove at the moment of access.
What practitioners should verify before relying on attestation
Attestation only works when the verifier understands what evidence is actually being asserted. A device integrity assertion should not be mistaken for proof that an app has not been instrumented, and an app state assertion should not be mistaken for proof that the device is uncompromised. The strongest designs bind the attestation result to the specific session, app build, and risk decision being made.
For mobile apps, this is where Mobile App Security Guide is useful because it places attestation alongside app testing, code integrity, and mobile platform controls. Teams should also align attestation with Mobile Device Security Guide so device posture, enrolment, and management state are part of the same decision.
When the subject is platform-backed proof, the mobile comparison is often easiest to understand through Hardware Security Keys Guide, because it shows how hardware-backed attestation depends on trusted device material. That mental model helps teams avoid overclaiming what hardware evidence can prove about the app runtime itself.
Risk and Threat Considerations
Attestation fails when defenders assume a signal means more than it really does. Hardware-backed proof can be diluted by ecosystem fragmentation or by a compromised application layer, while software attestation can be undermined if the attacker can hide in memory, hook APIs, or alter execution before the check runs.
Failure mechanism: An attacker spoofs, delays, or intercepts the evidence path, or compromises the layer not covered by the chosen attestation method. If the verifier treats device trust as app trust, or app trust as device trust, it can grant access on the basis of a partial signal.
Impact: The result can be false confidence, unauthorized access to sensitive mobile functions, and missed compromise on devices that still appear compliant. In high-value mobile workflows, that can become a direct path to account takeover, data exposure, or abuse of trusted app functionality.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Mobile attestation depends on runtime integrity and trust-boundary design. |
| Recommendation — Bind attestation checks to the app’s trust boundary and session state. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Mobile attestation supports stronger authentication decisions for non-org mobile users. |
| SI-7 — Software, Firmware, and Information Integrity | Software attestation is an integrity check on the running app and code state. | |
| Recommendation — Use attestations as part of authentication for external mobile users. Verify app and code integrity before granting sensitive mobile access. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Mobile attestation often protects API access decisions tied to app trust. |
| Recommendation — Require stronger proof before accepting mobile API authentication. | ||
| NIST Zero Trust (SP 800-207) | 0 — Zero Trust Architecture | Attestation is a device and workload trust signal used in continuous verification. |
| Recommendation — Continuously verify mobile trust signals before and during access. | ||
Practitioner Guidance
What to verify: Decide what the attestation is supposed to prove before you wire it into access policy. If the decision is about device trust, require hardware-backed evidence; if the decision is about live app integrity, require software attestation that is tightly bound to the current session and build.
Decision rule: If the mobile risk is rooted in device compromise, rooted/jailbroken environments, or platform trust, start with hardware-backed checks. If the risk is rooted in app tampering, runtime hooking, or integrity of the executing process, prioritise software attestation and treat the device result as supporting context, not the whole answer.
Practitioner takeaway: The key judgement is to map each attestation type to the layer it can actually prove, then avoid using one layer’s evidence as a proxy for the other.
Related resources from NHI Mgmt Group
- What is the difference between hardware-based and software-based passwordless security keys?
- What is the difference between secure software development attestation and a one-time security review?
- What is the difference between mobile app security testing and regulatory attestation?
- What is the difference between mobile application security testing and software bill of materials analysis?