Client identity is the way a connecting application, device, or service is recognised and trusted by a backend system. In mobile environments, it includes signing integrity, certificates, tokens, and network behaviour, all of which can be abused when an app impersonates a legitimate client.
Expanded Definition
Client identity describes how a backend system recognises a connecting application, device, or service as a trusted caller. In practice, that trust is rarely based on a single signal. It may combine certificates, signed app code, access tokens, device posture, transport properties, and behavioural signals. For mobile and API-driven environments, the concept overlaps with application attestation, workload identity, and device identity, but it is not identical to any one of them. Definitions vary across vendors, especially where mobile app protection, zero trust, and API security overlap.
At NHI Management Group, client identity is best understood as a security claim made by the calling side and verified by the receiving side before access is granted. The question is not only "who is the user?" but also "what is the calling client, and can it be trusted to speak for itself?" That distinction matters because a valid user session can still be driven by a compromised or fraudulent client. Guidance from the NIST Cybersecurity Framework 2.0 supports this trust-and-verification mindset even though the term itself is broader than any single control family.
The most common misapplication is treating client identity as equivalent to user authentication, which occurs when teams trust a session token without verifying whether the calling application or device is the legitimate client.
Examples and Use Cases
Implementing client identity rigorously often introduces device binding, certificate lifecycle, and attestation overhead, requiring organisations to weigh stronger caller assurance against operational complexity and user friction.
- A mobile banking app presents a signed application identity plus a device-bound token before the API gateway allows access to account data.
- A SaaS platform checks mTLS certificates and workload credentials to distinguish a legitimate automation client from a script that copied a token.
- An internal admin console validates endpoint posture and browser context before allowing privileged actions, reducing the chance that a stolen credential is used from an unmanaged device.
- An NIST Cybersecurity Framework 2.0-aligned program maps client trust checks to access control and continuous monitoring so that the backend can revoke trust when the client environment changes.
- A finance API compares request signatures, certificate chains, and unusual network routes to detect when a legitimate app package has been repackaged and used by an impostor client.
Why It Matters for Security Teams
Security teams need client identity because many modern breaches happen after an attacker defeats the front door but still fails to look like the expected caller. If a backend assumes that any request with a valid token is trustworthy, token replay, app repackaging, emulator abuse, and automated abuse can all bypass the intended control boundary. Client identity therefore becomes a practical control point for API security, mobile fraud prevention, workload-to-workload trust, and Zero Trust Architecture.
The identity connection is especially important in non-human and agentic environments. An AI agent or automation service may have legitimate execution authority, but that authority still depends on verifying the client instance, its credentials, and its runtime integrity. If those elements are weak, the organisation cannot reliably distinguish a sanctioned agent from a stolen or cloned one. For that reason, client identity is closely related to NHI governance even when it is not labelled that way in platform documentation.
Organisations typically encounter the consequences only after a stolen token, repackaged app, or rogue service has already been used at scale, at which point client identity becomes operationally unavoidable to address.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Client identity supports verifying who or what is allowed to access systems and data. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero trust requires explicit verification of devices, users, and workloads before access. |
| NIST SP 800-63 | AAL2 | Digital identity assurance informs how strongly a client or credential can be trusted. |
| OWASP Non-Human Identity Top 10 | NHI guidance covers non-human callers whose identities must be governed and monitored. | |
| OWASP Agentic AI Top 10 | Agentic systems require trustworthy client identity before tools or actions are executed. |
Validate caller identity before granting access and continuously reassess trust when signals change.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
