Device credentials are the protected certificate store on an Android device where installed certificates are registered for use by the operating system. Once a certificate is added there, it can support authentication for VPN, Wi-Fi, email, and other enterprise applications.
What Device Credentials Are Used For
Device credentials are the certificate material registered in an Android device’s protected certificate store so the operating system can use them for trusted authentication flows. They are commonly involved when a device must prove itself to enterprise services, networks, or managed applications.
Because the store sits inside the device trust stack, these credentials are not just passive files. They help determine which services the device can reach, which connections are trusted, and whether an organisation can treat the handset as an approved endpoint.
How Android Uses Device Credentials
On Android, installed certificates can support access paths such as VPN, Wi-Fi, email, and other enterprise applications. In practice, this means the credential may be used by the system or by managed apps to authenticate the device or to establish a trusted TLS or client-certificate connection.
This is why device credentials are often part of managed mobility and enterprise enrollment patterns. They can enable passwordless or certificate-based access, but they can also become a dependency for continued connectivity if the certificate is removed, expires, or is not distributed consistently.
Why Device Credentials Matter for Security
Device credentials are security material, not just configuration. If they are installed on an unmanaged or compromised device, they can extend enterprise trust to a device that no longer deserves it. If they are copied, leaked, or issued too broadly, they can create an access path that is difficult to distinguish from legitimate device activity.
They also shape the lifecycle of trust. Rotation, revocation, renewal, and offboarding all matter because a certificate that remains valid after a device should have lost access can keep authentication working longer than intended. For that reason, device credentials are often treated as part of broader certificate and secrets management, not merely device setup.
Where Device Credentials Fit in Enterprise Access
Device credentials sit at the boundary between endpoint management and identity-based access. They are frequently used alongside API Key Management Guide style lifecycle thinking, but the actual trust model is certificate-based rather than token-based. That distinction matters because a certificate can be bound to the device and its operating context, which makes it useful for managed access but also harder to inspect once deployed.
For readers who want a broader view of non-human and machine-style trust material, Ultimate Guide to NHIs, What are Non-Human Identities provides the surrounding identity model, while Secrets Management Guide explains why central control, rotation, and removal of trust material are essential once credentials become operational dependencies.
At the framework level, device credentials align strongly with OWASP Non-Human Identity Top 10 because certificates can function as machine trust material, and with NIST SP 800-63 Digital Identity Guidelines where authenticator assurance and strong device-bound proofing influence access decisions.
Risk and Threat Considerations
Device credentials create concentrated trust, so compromise can have outsized impact. If an attacker obtains a valid certificate from a device, the resulting access may look legitimate to downstream systems even if the device itself is no longer trustworthy.
Failure mechanism: Weak issuance, poor revocation, certificate reuse, or failure to remove credentials from retired or compromised devices can preserve access after trust should have ended.
Impact: The result can be unauthorized VPN, Wi-Fi, email, or application access, plus persistence that is difficult to spot because the authentication path still appears valid.
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 addresses the attack surface, NIST SP 800-53 Rev 5, NIST SP 800-63 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Device certificates are a non-human auth mechanism that can be misissued or misused. |
| NHI-05 — Overprivileged NHI | Certificates on devices can grant broader access than the device needs. | |
| NHI-07 — Long-Lived Secrets | Certificates become risky when they remain valid beyond the device's trust window. | |
| Recommendation — Use device-bound certificates with strong enrollment and authentication checks. Scope each device credential to the minimum services and networks required. Set short validity periods and enforce renewal and revocation discipline. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Device credentials are authenticators whose issuance, rotation and revocation must be managed. |
| IA-9 — Service Identification and Authentication | Device certificates support machine-to-service authentication and trust establishment. | |
| Recommendation — Manage certificate issuance, storage, rotation and revocation as controlled authenticators. Use certificate-based authentication for device-to-service trust where appropriate. | ||
| NIST SP 800-63 | IAL1 — Identity Assurance Level 1 | Device credential use depends on the assurance model behind the enrolled identity. |
| AAL2 — Authentication Assurance Level 2 | Certificate-backed device access commonly supports stronger authentication than passwords alone. | |
| Recommendation — Bind device authentication to the assurance level required for the access path. Require phishing-resistant or certificate-backed authentication where the service demands it. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Device credentials are authentication information that must be protected and controlled. |
| Recommendation — Protect device certificate material with formal handling, storage and recovery controls. | ||
| CIS Controls v8 | CIS-5 — Account Management | Device credentials affect access lifecycle and should be tied to enrollment and offboarding. |
| CIS-6 — Access Control Management | Certificates govern which devices can reach which services and should be access-scoped. | |
| Recommendation — Remove device credentials promptly when the device is retired, lost or decommissioned. Restrict certificate-based access to the smallest feasible set of systems and users. | ||
Practitioner Guidance
Governance implication: Treat device credentials as governed trust material with an owner, a lifecycle, and a revocation path. Their value depends on the organisation being able to answer who issued them, where they are installed, and when they should stop working.
What to watch for: Certificates that outlive the device, appear across unexpected endpoints, or are used outside the intended enrollment model usually signal control drift. The practical question is not only whether the credential exists, but whether it still belongs on that device and still deserves to authenticate it.
Related resources from NHI Mgmt Group
- How should security teams govern device-bound payment credentials in open finance?
- How should security teams choose between API keys, Device Flow, and Client Credentials for CLI apps?
- What is the difference between Device Flow and Client Credentials for terminal access?
- How can IAM teams reduce the impact of browser or device compromise on credentials?
