Relayed provisioning is an identity provisioning pattern that uses an intermediate software layer between the identity management system and the target application. It helps organisations connect to systems that are difficult to integrate directly, while still allowing account creation, updates, and removal to be governed centrally.
Expanded Definition
Relayed provisioning is used when a central identity platform cannot reach a target system directly, so an intermediate layer translates provisioning requests into the format, transport, or protocol that the target accepts. In NHI environments, this pattern is common where legacy applications, industrial systems, or partner-managed platforms cannot support native modern connectors. The security question is not whether provisioning is centralised, but whether the relay preserves policy enforcement, auditability, and lifecycle integrity across every hop.
Definitions vary across vendors on whether the relay is treated as an integration broker, an agent, or a provisioning gateway. NHI Management Group treats the term as an architectural control point, not a product category. That distinction matters because the relay must not become an uncontrolled shadow admin path or a place where approvals, rotation logic, and deprovisioning are bypassed. For lifecycle discipline, see the NHI Lifecycle Management Guide and the lifecycle section in the Ultimate Guide to NHIs. The closest standards-aligned control set is NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasises managed access, audit logging, and configuration discipline.
The most common misapplication is treating the relay as a trusted exception path, which occurs when integration teams grant it broad standing permissions without lifecycle review.
Examples and Use Cases
Implementing relayed provisioning rigorously often introduces latency and operational dependency on the middleware layer, requiring organisations to weigh integration reach against extra failure modes and oversight burden.
- A legacy payroll system only accepts flat-file imports, so the relay transforms identity system events into scheduled file drops while preserving approval records.
- A partner-hosted application cannot expose a modern API, so the relay mediates account creation and disablement while the central IAM platform remains the policy source of truth.
- A manufacturing environment uses a local provisioning agent to bridge segmented networks, reducing direct exposure while still supporting onboarding and offboarding.
- A regulated SaaS tenant requires a custom connector, so the relay enforces attribute mapping and logs every entitlement change for audit review.
This pattern is closely related to the provisioning and lifecycle issues described in Top 10 NHI Issues, especially where account sprawl and incomplete deprovisioning create exposure. In control language, the same operational discipline aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls for controlled interfaces, accountability, and system integrity.
Why It Matters in NHI Security
Relayed provisioning matters because it often becomes the practical route for creating, updating, and revoking non-human accounts in systems that would otherwise fall outside governance. That makes the relay a high-value control point for secrets handling, entitlement changes, and offboarding. If it is poorly designed, the organisation may believe identity governance is in place while the relay quietly introduces orphaned accounts, stale credentials, or inconsistent attribute mapping. NHI Management Group research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which magnifies the risk when relay components also handle credentials or tokens.
Good relayed provisioning supports Zero Trust by preserving central policy decisions even when integration is indirect. Bad relays undermine that model by creating hidden trust zones, unmanaged service credentials, and weak audit trails. The governance test is simple: every action taken by the relay should be attributable, reversible, and tied to a lifecycle event. The most common failure mode appears after a breach review or access recertification, when teams discover that account removal never propagated cleanly and the relay has been maintaining access long after it was approved to end.
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 NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Relayed provisioning can create hidden lifecycle and access control gaps for NHIs. |
| NIST CSF 2.0 | PR.AC-4 | Managed access paths must still enforce least privilege and controlled account lifecycle. |
| NIST Zero Trust (SP 800-207) | Indirect provisioning paths must not become implicit trust zones in a Zero Trust model. | |
| NIST SP 800-63 | AAL2 | Provisioning workflows should be bound to strong assurance for administrative actions. |
| NIST AI RMF | Relay-mediated automation needs governance over risks, monitoring, and accountability. |
Treat the relay as untrusted infrastructure and continuously verify each provisioning transaction.
Related resources from NHI Mgmt Group
- How should security teams implement relayed provisioning in complex identity environments?
- When does relayed provisioning make more sense than direct system integration?
- What is the difference between just-in-time provisioning and just-in-time access?
- What is the difference between access certification and provisioning?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
