Compromised-device testing

Expanded Definition

Compromised-device testing is a security validation method that assumes the client endpoint has been taken over, tampered with, or instrumented by an attacker. The goal is not to prove that a device remains clean, but to see whether the application still protects secrets, enforces session boundaries, and resists unauthorized actions when local trust has collapsed.

That makes it different from ordinary penetration testing or baseline vulnerability scanning. Those methods often focus on network exposure, input handling, or misconfiguration. Compromised-device testing instead asks what happens after the endpoint is already hostile, including whether cached tokens can be replayed, whether local storage is readable, and whether sensitive workflows degrade safely. For applications that support Zero Trust Architecture, the endpoint should never be treated as implicitly trustworthy, so this type of testing is a direct way to validate that assumption.

Definitions vary across vendors because some teams use the term narrowly for mobile or desktop compromise, while others apply it to managed devices, browser sessions, or agentic application runtimes. At NHI Management Group, the useful boundary is simple: if an attacker controls the device, does the application still limit blast radius and protect identities, secrets, and data?

The most common misapplication is treating device compromise as a mere loss of endpoint integrity, which occurs when teams test only crash behaviour or malware detection and never validate what an attacker can do with live session state.

Examples and Use Cases

Implementing compromised-device testing rigorously often introduces operational and privacy constraints, because realistic scenarios may require controlled instrumentation, restricted test accounts, and careful handling of production-like data.

• Testing whether a stolen laptop with an active browser session can access administrative functions without reauthentication or step-up controls.
• Validating whether locally stored API keys, refresh tokens, or certificates can be extracted and reused after the device is rooted or jailbroken.
• Checking whether an internal application still protects sensitive records when endpoint malware can observe clipboard activity, screen contents, or browser storage.
• Assessing whether an AI-enabled desktop tool leaks prompts, model outputs, or connected credentials when the endpoint is under attacker control, a concern highlighted in Anthropic’s report on AI-orchestrated cyber espionage.
• Simulating a compromised mobile device to confirm that sensitive transactions fail closed rather than continuing with stale trust.

In environments that use identity-aware access controls, the test should also confirm that the application reacts to device risk in a measurable way, such as shortening session lifetime or requiring reauthentication. This aligns with the broader assurance mindset in NIST SP 800-63B, where authenticator and session handling must account for the possibility of compromise. In practice, the most useful scenarios are those that resemble realistic attacker persistence rather than a single one-off exploit.

Why It Matters for Security Teams

Security teams often discover weak assumptions about endpoint trust only after an incident shows that sessions, tokens, or local data can be abused outside the intended control plane. Compromised-device testing helps expose those assumptions earlier, before an attacker turns a single compromised endpoint into broader account takeover, data theft, or operational misuse.

For identity-heavy applications, the endpoint is often the bridge between user authentication and ongoing authorization. If the bridge is fragile, a valid login can still become a security failure once the device is controlled by malware, a malicious insider, or an untrusted remote access tool. That is why this testing is relevant not only to endpoint security teams, but also to IAM, PAM, and NHI governance when long-lived secrets or automation credentials are present on the device.

Teams that use browser-based access, remote work tooling, or AI agents with local tool access should be especially careful. A compromised workstation can expose more than user data; it can expose the operational identity of the software running on it, including tokens, service accounts, and delegated actions. As a result, guidance from NIST AI Risk Management Framework is increasingly relevant when applications rely on AI-enabled clients or agentic workflows.

Organisations typically encounter the real cost of compromised-device weaknesses only after a session hijack, secret theft, or fraudulent transaction, at which point the testing term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams handle authentication when device trust may be compromised?
• How can teams reduce risk when agents use webcam or device-like inputs during testing?
• How should teams detect mobile fraud when the device itself is compromised?
• Who is accountable when a compromised mobile device completes a fraudulent transaction?