Use separate lifecycle and certification rules for third parties and machine identities because their access patterns, ownership, and offboarding triggers differ from employee accounts. Third-party access should expire with the relationship, and machine identity access should be tied to service ownership, rotation, and revocation events rather than HR changes.
How to govern third-party and machine identity access in one IGA programme
Third-party and machine identity access can live in the same IGA programme, but they should not share the same lifecycle logic. Third parties are governed by relationship terms, contract end dates, and sponsor accountability. Machine identities are governed by service ownership, technical dependency, and events such as rotation, decommissioning, or workload retirement. The common control plane is IGA, not a common review rule.
That distinction matters because the security question is not only who has access, but what event should end it. If you treat every identity as employee-like, you will miss machine access that outlives a system change and third-party access that persists after the business relationship has ended. If you treat everything as non-human, you will lose the ability to tie access decisions to external accountability and contractual offboarding.
What should be shared, and what must stay separate?
The shared layer is inventory, ownership, approval workflow, attestation, and revocation. Both populations need discoverability, explicit owners, entitlement visibility, and evidence that access was granted for a reason. NHIMG’s IAM and IGA Basics is useful here because it frames access governance as a common discipline while still distinguishing different identity types and review models.
The separate layer is the policy that drives certification and removal. Third-party access should be certified against sponsor and vendor relationship data, then revoked when the contract, engagement, or access window ends. Machine identity access should be certified against service ownership, runtime need, and technical lifecycle events. The most common mistake is to put both into a single quarterly recertification campaign and assume a single reviewer can judge them well.
For machine identities, lifecycle is usually the stronger control than calendar review. NHIMG’s NHI Lifecycle Management Guide fits that operating model because it emphasises provisioning, rotation, offboarding, and visibility as the core control cycle. For third parties, the stronger control is relationship-bound access with expiry, sponsor verification, and rapid termination when the business need stops.
How to design certification, ownership, and offboarding rules
Use different review triggers for each population. Third-party access should be reviewed on a fixed cadence and also on relationship events such as contract renewal, vendor change, or sponsor change. Machine identity access should be reviewed when the underlying service changes, when credentials or certificates rotate, when a workload is retired, or when an integration is no longer deployed. NHIMG’s Human vs Non-Human Identity is a helpful comparison when designing these separate review triggers, especially where people and machine access intersect through delegated or shared use cases.
Ownership should also be different. Third-party access needs a business sponsor and a control owner who can attest that the relationship still exists. Machine identity access needs a technical owner who can confirm the service still requires the entitlement and can act on rotation or revocation. NHIMG’s NHI Ownership and Accountability Guide supports that model by treating ownership as a prerequisite for meaningful governance rather than an administrative label.
Offboarding should be event-driven, not purely periodic. When a third-party relationship ends, access should be disabled immediately, not left to the next review cycle. When a machine is decommissioned, migrated, or replaced, its credentials, tokens, certificates, and secrets should be revoked as part of the technical shutdown path. NHIMG’s Service Account Security Guide is relevant where the machine identity is implemented as a service account and the governance problem becomes one of least privilege, rotation, and removal.
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, CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Covers identity governance for third-party and machine access across cloud environments. |
| Recommendation — Separate lifecycle rules for third-party and machine identities and enforce ownership-based revocation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Applies to managing credentials, rotation, and revocation for machine identities. |
| AC-2 — Account Management | Supports account lifecycle, ownership, and removal of both third-party and machine access. | |
| AC-6 — Least Privilege | Limits third-party and machine identities to the minimum access required for their function. | |
| Recommendation — Tie machine identity access to credential rotation, expiry, and revocation events. Inventory, approve, review, and disable non-employee accounts on their true lifecycle triggers. Scope each non-employee entitlement to the minimum permissions needed for the task. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Directly governs access policy design and role-specific control for mixed identity populations. |
| A.5.18 — Access rights | Supports granting, reviewing, and removing access rights on owner and lifecycle events. | |
| Recommendation — Define distinct access rules for third-party and machine identities within the access control policy. Review and remove access rights when sponsorship, service ownership, or contracts change. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Addresses account lifecycle, access reviews, and least privilege for governed identities. |
| Recommendation — Manage non-human and third-party accounts through inventory, review, and timely deprovisioning. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Third-party and machine identities both create stale-access risk when offboarding is not event-driven. |
| NHI-05 — Overprivileged NHI | Machine identities often accumulate excess permissions if they share review logic with people. | |
| NHI-07 — Long-Lived Secrets | Machine identities often depend on secrets that outlast their intended service lifecycle. | |
| Recommendation — Revoke access immediately when the relationship or service lifecycle ends. Reduce machine identity entitlements to the minimum required by the service. Rotate and retire machine secrets on service changes, not on arbitrary calendar cycles. | ||
Practitioner Guidance
What to prioritise: Build one IGA inventory and two policy paths. The inventory should show whether the identity is third-party or machine, who owns it, what it can reach, and what event should remove it. That classification must happen before certification starts, otherwise reviewers will apply the wrong standard.
What to verify: For third parties, verify sponsor, contract status, and expiry date. For machine identities, verify service owner, deployment status, secret or certificate lifecycle, and whether the identity is still used by a live dependency. If you cannot name the removal trigger, the access is not governed well enough.
Common mistake: Do not rely on employee joiner-mover-leaver logic for either population. Third-party access is relationship-bound, not HR-bound, and machine access is system-bound, not calendar-bound. A single recertification campaign can still be useful, but only if it feeds different removal rules downstream.
Practitioner takeaway: The right model is unified governance with differentiated lifecycle logic, because effective IGA is measured by how precisely it removes access when the real-world reason for that access disappears.
Related resources from NHI Mgmt Group
- How should organisations govern human and machine identities as identity estates scale across cloud and third-party access?
- How should organisations govern third-party identity access more tightly?
- How should identity teams govern human and machine access in the same programme?
- How should security teams govern third-party identity access?