Why do open communication standards create new access governance challenges?

Why This Matters for Security Teams

Open communication standards are attractive because they let separate systems interoperate without a single vendor owning the full stack. That same openness creates a governance problem: trust is no longer contained inside one platform, so access can be granted, extended, or forgotten across organisations, devices, APIs, and intermediary services. Security teams have to govern identity, not just connectivity.

This is where NHI risk becomes operational. Shared protocols can make it easier for service accounts, API keys, tokens, and automation pathways to proliferate faster than review processes can track. NHIMG’s research shows the scale of the problem: 72% of organisations have experienced or suspect a breach of non-human identities, according to the 2024 ESG report on managing non-human identities. In practice, teams often discover that “open” has really meant “unowned” only after third-party integrations, OAuth connections, or service-to-service trust relationships have already expanded beyond policy.

That is why open standards cannot be treated as a technical convenience alone. They require explicit governance for onboarding, delegation, scope, and revocation, especially when access crosses organisational boundaries. The baseline control mindset is reinforced by NIST Cybersecurity Framework 2.0 and by the identity-specific risks described in Top 10 NHI Issues. In practice, many security teams encounter the governance gap only after a partner integration or toolchain change has already created standing access that nobody formally approved.

How It Works in Practice

With open standards, access is usually expressed through tokens, assertions, signed messages, certificates, or delegated credentials that are meant to be understood by more than one system. That interoperability is useful, but it also means no single control plane automatically enforces the full access decision. Security teams have to decide who is allowed to join the trust fabric, what claims are trusted, how scopes are limited, and how long a permission remains valid.

In practice, governance works best when it is tied to identity lifecycle controls rather than just protocol adoption. A useful operating model is to define:

• approved issuers and relying parties
• minimum claims required for access
• scope restrictions for each integration or workload
• expiry and revocation rules for tokens and certificates
• review points for partner, vendor, and internal service changes

This is also where OWASP Non-Human Identity Top 10 is especially relevant, because open standards often amplify familiar failure modes such as weak secret handling, over-privilege, and missing rotation. NHIMG’s lifecycle guidance for managing NHIs is the practical complement: every standardised trust relationship still needs onboarding approval, inventory, monitoring, and offboarding. Current guidance suggests that teams should treat the protocol as the transport layer for trust, not as the trust decision itself.

The governance model usually works when the environment is bounded and the number of participants is known. These controls tend to break down in large partner ecosystems with nested sub-processors and cross-domain automation because ownership, revocation, and audit evidence become fragmented across multiple administrators.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance interoperability against control fidelity. That tradeoff is especially visible when open standards are used for external collaboration, where every additional approval step can slow delivery, but every shortcut can widen the blast radius of a compromised credential.

There is no universal standard for this yet, but best practice is evolving around contextual, risk-based access decisions. For example, a vendor token issued for read-only telemetry should not be treated the same way as a token that can trigger workflows or modify records. Similarly, some teams allow broad protocol compatibility but restrict high-risk actions to short-lived credentials with explicit reauthorisation. That approach aligns with the access governance emphasis in NHIMG’s regulatory and audit perspective.

Edge cases are most common when:

• a standard supports delegation but does not define organisational approval rules
• a partner environment changes its signing authority or token policy without notice
• machine-to-machine access is inherited through a chain of tools and brokers
• revocation exists technically but is not operationally enforced across all systems

In those cases, the real control is not the standard itself but the governance process wrapped around it. The security objective is to make trust explicit, reviewable, and removable across every domain that participates in the exchange.

Related resources from NHI Mgmt Group

• When does third-party access create insurance and governance risk?
• When does AI help identity governance, and when does it create new risk?
• Why do shared workstations create IAM governance challenges?
• When do NHI access reviews create more value than a one-time cleanup?