A single machine identity used by an integration to act across an entire tenant or organisation. Unlike a per-user token, it can carry broad permissions and persist as long as the integration remains enabled, which makes ownership, scoping, and revocation central governance tasks.
Expanded Definition
An org-level connector identity is a tenant-wide NHI that lets one integration perform actions across an entire organisation instead of acting on behalf of a single user. In practice, it sits closer to a privileged service principal than a delegated end-user token, so governance must focus on scope, ownership, and revocation rather than convenience.
Definitions vary across vendors when this pattern is called a connector, app registration, bot account, or integration identity, but the security question is the same: does one credential gain broad organisational reach without sufficient containment? NIST Cybersecurity Framework 2.0 provides a useful governance lens for identifying, protecting, and monitoring these identities because the operational risk is concentrated in access control and lifecycle discipline, not in authentication alone. NHI Management Group treats this as an NHI design pattern that requires explicit boundaries, even when the platform presents it as a simple integration setting.
The most common misapplication is treating an org-level connector identity like a harmless automation token, which occurs when teams grant broad permissions and leave the identity active after the integration’s original purpose has changed.
Examples and Use Cases
Implementing org-level connector identities rigorously often introduces administrative overhead, requiring organisations to balance easier integration rollout against tighter ownership, approval, and monitoring controls.
- A security analytics connector reads tenant-wide audit logs to detect suspicious activity. If it can also modify alerting rules, its blast radius increases unless permissions are split by function.
- A SaaS provisioning integration creates and updates accounts across the tenant. In this pattern, lifecycle ownership must be tied to a named system owner, not an individual engineer.
- An incident-response automation uses one identity to isolate endpoints or revoke access during compromise. This should be time-bound and reviewed against the guidance in the Ultimate Guide to NHIs.
- A data-sync connector exports records from multiple business units. If the identity has long-lived secrets, the organisation should compare its handling to the monitoring and rotation expectations described in Top 10 NHI Issues and the identity assurance concepts in NIST Cybersecurity Framework 2.0.
- A cross-tenant admin connector is used by a managed service provider to administer customer environments. This is one of the highest-risk forms because compromise of the connector identity can become a direct path to large-scale tenant exposure.
In each case, the operational challenge is not whether the connector is useful, but whether its authority is sufficiently narrowed, logged, and revocable.
Why It Matters in NHI Security
Org-level connector identities matter because they compress risk into a single machine credential with broad reach. That makes them attractive to attackers and dangerous when ownership is unclear, especially in environments where integrations outlive the teams that created them. NHI Management Group reports that 97% of NHIs carry excessive privileges, a pattern that directly amplifies the impact of these connector identities when permissions are granted for convenience rather than necessity. The findings in 52 NHI Breaches Analysis show how identity misuse often becomes visible only after access has already been abused, while the broader lifecycle lessons in the Ultimate Guide to NHIs stress rotation, offboarding, and visibility as baseline controls.
Practitioners should treat this term as a governance trigger: every org-level connector identity needs an owner, a defined purpose, minimal permissions, a revocation path, and monitoring that can detect expansion of use beyond the original integration scope. Organisational exposure typically becomes apparent only after an integration is abused or retired without offboarding, at which point the connector 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 address the attack and risk surface, while 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-02 | Covers risky secret handling and overprivileged machine identities. |
| NIST CSF 2.0 | PR.AC-4 | Maps to least-privilege access management for machine identities. |
| NIST Zero Trust (SP 800-207) | SC | Zero Trust requires continuous verification of broad service access paths. |
Treat org-level connectors as high-trust paths that must be segmented and monitored.
Related resources from NHI Mgmt Group
- What is the difference between network trust and request-level identity trust?
- What breaks when an AI identity has production-level privileges but no clear owner?
- What breaks when identity controls stop at table-level permissions?
- What breaks when an agent spawns subagents without chain-level identity tracking?
