A cross-system relationship is a link between identities or permissions in different platforms that changes what an identity can do. These relationships are often invisible in isolated entitlement reviews, yet they are a common source of escalation and hidden control.
Expanded Definition
A cross-system relationship is a dependency or entitlement link that connects one identity, workload, or permission set to another platform, and then changes what that identity can do. In NHI and IAM practice, the key issue is not the individual account in isolation, but the effective access created when systems trust each other across boundaries. This can include service account inheritance, federated roles, token exchange paths, delegated admin rights, or CI/CD relationships that allow one system to act as another. The concept overlaps with federation and authorization chaining, but it is narrower in operational risk because it focuses on the hidden access created by the relationship itself. Definitions vary across vendors, especially when platform-native trust graphs are blended with entitlement analytics, but the security meaning is consistent: a relationship can become an unreviewed privilege path. The most common misapplication is treating each platform as a separate access domain, which occurs when entitlement reviews ignore how access is amplified through cross-system trust.
For context on broader identity governance and Zero Trust expectations, see NIST Cybersecurity Framework 2.0.
Examples and Use Cases
Implementing cross-system relationship analysis rigorously often introduces correlation overhead, requiring organisations to weigh deeper visibility against longer review cycles and more complex access modelling.
- A workload in one cloud platform assumes a role in a second account, which then permits database writes that the original workload never had directly.
- A CI/CD pipeline uses a build token to mint a short-lived credential in a deployment platform, creating a chain of authority that outlives simple secret inventory checks.
- A SaaS admin account delegates approval rights to an automation service, allowing that service to modify permissions for other identities without a human touchpoint.
- An API gateway trusts tokens issued by an external identity provider, and mis-scoped claims let one service call another service with expanded privileges.
- A service account is added to a group in one directory, which then maps into a privileged role in a downstream application, producing indirect escalation.
These patterns are especially visible when reviewing NHI sprawl and secret distribution in the Ultimate Guide to NHIs, and they align with the identity governance focus of NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Cross-system relationships are a major reason NHI risk remains invisible during isolated reviews. When a service account, API key, or agent inherits access through another platform, the effective privilege often exceeds what any single system reports. That matters because NHIs already represent a high-risk control surface: NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs. Cross-system relationships convert those excessive privileges into reachable attack paths, especially when secrets are reused, federated trust is loosely scoped, or offboarding only removes access in one system. Practitioners also need to align these relationships with broader Zero Trust controls, because trust propagation is where policy drift becomes exploitable. Organisational exposure typically becomes obvious only after a compromised account is used to traverse from one system into another, at which point cross-system relationship mapping becomes operationally unavoidable to address.
For implementation patterns that reduce hidden trust paths, practitioners can also reference NIST Cybersecurity Framework 2.0 and treat every cross-platform grant as a reviewable access dependency.
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) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Cross-system trust paths create hidden privilege relationships beyond direct entitlements. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access must account for inherited access across connected systems. |
| NIST Zero Trust (SP 800-207) | SC-2 | Zero Trust requires continuous validation of trust relationships between systems. |
| NIST SP 800-63 | Federated identity chains affect assurance, even when direct credentials are not reused. |
Inventory and review transitive access paths so each dependency remains least privilege.
