A non-human or delegated identity that is owned and operated by an outside organisation rather than by the environment it accesses. The runtime shape may resemble any other machine identity, but the accountability, review cadence, and incident response model must account for the external controller.
Expanded Definition
Vendor-controlled identity is a delegated or non-human identity whose operator, approval path, and recovery process sit outside the environment that uses it. In practice, it behaves like any other machine or service identity at runtime, but the ownership boundary is different, and that changes who can approve access, rotate credentials, revoke access, and respond to compromise.
The key boundary is accountability, not just technical form. A team may authenticate with a token, certificate, or service account that looks ordinary inside logs and access policies, yet the external organisation still controls how that identity is issued or reissued. That means policy decisions must account for third-party cadence, contractual obligations, and visibility into lifecycle events. The concept is closely related to broader non-human identity governance, and the OWASP Non-Human Identity Top 10 is a useful reference point for the control problems that appear when machine identities are not governed cleanly.
A common misunderstanding is to treat a vendor-controlled identity as “just another integration account.” That framing misses the external control plane, which often determines whether access can be tightened quickly when risk changes.
Examples and Use Cases
Vendor-controlled identity shows up anywhere an outside party needs persistent or semi-persistent access into your systems:
- A SaaS provider uses its own service identity to sync records, monitor events, or push notifications into your tenant.
- A managed security tool authenticates to your cloud environment using credentials the vendor provisions and rotates.
- A software supplier’s build or support workflow uses an API key or certificate that your team can observe but does not fully own.
- A third-party automation platform calls internal APIs on a schedule, with revocation and rotation tied to the vendor’s operational process.
These designs can be efficient because they reduce manual coordination, but they also make trust and revocation dependent on a third party’s process maturity. That trade-off matters most when the identity has broad read access, privileged write access, or long-lived credentials.
NHIMG’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which is a strong signal that this governance pattern is common enough to warrant explicit ownership.
Security Implications
The main security issue is loss of direct control over a credential that can still reach high-value assets. If the vendor delays rotation, mishandles revocation, or continues using an identity after your internal trust assumptions have changed, the exposure can persist long after the original business need has shifted.
Failure usually appears as weak lifecycle visibility: teams know the integration exists, but not who can actually reissue the credential, how quickly it can be revoked, or whether it is still being used by the vendor’s tooling. That creates blast-radius problems during incidents because the organisation may be forced to coordinate containment through support channels rather than through its own control plane.
NHIMG reports that 91.6% of secrets remain valid five days after notification, which illustrates how remediation delays can extend exposure when external identity control is part of the path.
A practitioner should watch for identities that are created for convenience, then quietly become production dependencies with no clear sunset, renewal owner, or emergency disable path.
Security, Operational and Governance Implications
Vendor-controlled identity matters because the control model must follow the ownership model. Even if the runtime permissions are narrow, the governance burden is higher when an outside organisation controls issuance, rotation, or incident response. That is especially important for third-party access into cloud platforms, APIs, and administrative interfaces.
From an operational perspective, the question is not only “what can this identity do?” but also “who can act on it quickly enough when something changes?” If the answer depends on vendor support tickets, contractual escalation, or delayed maintenance windows, the identity needs tighter monitoring and clearer business ownership.
The most useful governance stance is to treat these identities as shared-risk assets: document the business owner, the technical owner, the vendor contact, and the revocation path together. In practice, that is what separates a manageable integration from an opaque dependency that can outlive the risk it was meant to solve.
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 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Ownership and Lifecycle | Vendor-controlled identities hinge on external ownership and lifecycle control. |
| NHI-02 — Secrets and Credential Management | These identities often depend on tokens, keys, or certificates managed outside the tenant. | |
| NHI-09 — Third-Party Access and Supply Chain Exposure | The core risk is delegated access controlled by an outside organisation. | |
| Recommendation — Define external ownership, renewal, and revocation paths for every third-party identity. Store, rotate, and revoke third-party credentials through controlled lifecycle processes. Review third-party access paths as supply-chain dependencies and constrain their blast radius. | ||
| CIS Controls v8 | 6 — Access Control Management | Vendor-controlled identity requires explicit authorization, review, and removal of external access. |
| 5 — Account Management | The subject is fundamentally about who owns and manages non-human accounts. | |
| Recommendation — Inventory external access and remove unused vendor identities on a defined schedule. Assign named owners and lifecycle rules for every vendor-managed account. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | External identities must still be authenticated, authorised, and governed within the environment. |
| Recommendation — Apply access governance to vendor identities with least privilege and periodic review. | ||
| NIST Zero Trust (SP 800-207) | 5 — Policy Decision and Enforcement | Vendor-controlled access must be continuously evaluated and enforced at runtime. |
| Recommendation — Enforce policy decisions that continuously validate third-party identity access. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
