Should organisations include proxy connectors in access reviews?

Why This Matters for Security Teams

Proxy connectors are easy to overlook because they often look like plumbing rather than privilege. In reality, they sit inside the trust chain that brokers access between a cloud identity layer and an internal application. That means the connector’s host permissions, service account, network reach, and stored secrets can all become part of the attack path. Current guidance from OWASP Non-Human Identity Top 10 treats hidden identity paths and excessive privilege as core governance problems, not edge cases.

This is also where the scale of NHI risk becomes visible. NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. If proxy connectors are left out of access reviews, teams may certify the application while ignoring the mechanism that actually enables access. That gap matters because reviewers tend to focus on named users and app owners, while the connector remains a silent privileged intermediary. In practice, many security teams encounter connector abuse only after lateral movement or unexplained application access has already occurred, rather than through intentional review.

How It Works in Practice

A good access review should treat the connector as a privileged workload identity, not as a neutral network component. Reviewers should confirm who owns it, what it can reach, what credentials it uses, whether those credentials are rotated, and whether the connector is scoped to one application or multiple sensitive targets. The objective is to verify that the connector’s permissions match the minimum needed to broker the intended path, and that there is an accountable approver for any exception.

The review should also examine how the connector is deployed. If it runs on a shared host, inherits broad admin rights, or stores static secrets outside a vault, the review should flag that as an identity risk. That aligns with the broader NHI lifecycle guidance in the NHI Lifecycle Management Guide, which emphasises ownership, rotation, and retirement of non-human identities. For teams looking to benchmark their review logic, the Ultimate Guide to NHIs — Key Challenges and Risks is useful for mapping where hidden privilege accumulates.

• Confirm the connector is tied to a named service owner and reviewed on the same cadence as other privileged access.
• Validate its runtime permissions, network paths, and any ability to reach more than one application.
• Check for long-lived secrets, cached tokens, and unmanaged certificates.
• Require evidence of rotation, offboarding, and break-glass procedures.
• Document compensating controls where the connector cannot yet be reduced to least privilege.

These controls tend to break down when the connector is embedded in legacy integration platforms because entitlement data, host permissions, and application ownership are often split across separate teams.

Common Variations and Edge Cases

Tighter connector review often increases operational overhead, so organisations have to balance stronger assurance against release friction and support burden. That tradeoff is real, especially where proxy connectors are used for many back-end services rather than a single application.

One common exception is a read-only connector that truly cannot modify data or expand its reach. Even then, current guidance suggests it should still be reviewed if it can access sensitive records, impersonate a service account, or relay credentials to downstream systems. Another edge case is a vendor-managed connector. Outsourcing operation does not remove the need to review its trust boundary; it simply changes the evidence requirements and escalation path.

There is no universal standard for how often every connector must be reviewed, but best practice is to align frequency with blast radius. A connector that reaches multiple critical apps should be reviewed more often than one that is tightly scoped and well-rotated. For broader context on why hidden NHI privilege matters, the 52 NHI Breaches Analysis and OWASP Non-Human Identity Top 10 both show how secondary identity paths become primary breach paths when they are left out of governance.

In practice, the safest rule is simple: if the connector can authenticate, relay, or widen access, it belongs in the review.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• When do NHI access reviews create more value than a one-time cleanup?
• When should organisations treat machine access as a high-risk identity problem?
• Should organisations prioritise SaaS cleanup before expanding access controls?