Who is accountable when telecom privileged access controls fall short?

Why This Matters for Security Teams

When privileged access controls fail in telecom, accountability does not shift to the supplier, the vault, or the platform team. The organisation that owns the critical function is still responsible for proving who can access what, when that access is approved, and how it is revoked. That matters because telecom environments often combine legacy administration paths, shared services, and third-party operations, which makes gaps easy to hide until a real incident forces the issue. Guidance from the OWASP Non-Human Identity Top 10 reinforces that machine credentials and service identities need explicit governance, not assumptions built around human-centric access models.

NHIMG research shows how often this is not just a theoretical concern: the Ultimate Guide to NHIs reports that only 5.7% of organisations have full visibility into their service accounts, while 92% expose NHIs to third parties. That combination makes telecom accountability especially sensitive, because privileged paths are frequently shared across internal teams, MSSPs, and managed network tooling. In practice, many security teams encounter the control failure only after an audit finding, outage, or breach has already exposed the absence of a clear owner.

How It Works in Practice

Accountability needs to be assigned at the level of the business service, not just the infrastructure layer. For telecom, that means the critical function owner, CISO, IAM lead, and platform operator each have a defined role in approving access, monitoring usage, and ensuring revocation. Current best practice is to pair that ownership model with explicit non-human identity governance, including secrets inventory, access review, and lifecycle controls described in the Ultimate Guide to NHIs — Key Challenges and Risks.

Operationally, the strongest pattern is:

• Map every privileged account, API key, certificate, and service account to a named control owner.
• Separate approval authority from technical administration so no single supplier can self-authorise standing access.
• Enforce short-lived access where possible, with documented revoke paths for break-glass and third-party sessions.
• Require evidence of review, rotation, and offboarding, not only policy statements.

Telecom teams often align this with identity assurance guidance such as NIST SP 800-63 Digital Identity Guidelines for authentication strength, while using NHI lifecycle controls for machine access. PCI-oriented environments often borrow from PCI DSS v4.0 expectations around least privilege and access verification, but there is no universal standard for telecom-specific supplier accountability yet. These controls tend to break down when the operator cannot produce a current inventory of service identities because approvals, secrets, and logs live in separate tooling.

Common Variations and Edge Cases

Tighter privileged access control often increases operational overhead, requiring organisations to balance security assurance against service continuity. That tradeoff is especially visible in telecom, where 24/7 availability, emergency maintenance, and roaming integrations can tempt teams to leave standing access in place.

There is also a genuine edge case when a supplier runs the platform but the telecom operator owns the regulated service. In that situation, accountability remains with the operator, but evidence collection may need joint controls, shared attestations, and contractual revocation timelines. Best practice is evolving here, especially for multi-tenant network operations and outsourced SOC models.

Two patterns are frequently missed. First, shared admin groups can obscure whether an action was approved for one function or silently inherited across several. Second, emergency access is often treated as an exception, then becomes the default path because no one tests the revoke process. NHIMG notes that 97% of NHIs carry excessive privileges in its Ultimate Guide to NHIs — Standards section, which is a useful reminder that telecom teams need ownership, review, and rotation discipline even when the underlying platform is shared. In practice, accountability fails fastest when organisations assume that a vendor-managed control is the same thing as a vendor-owned risk.

Related resources from NHI Mgmt Group

• Who is accountable when privileged access controls fail in cloud environments?
• Who is accountable when behaviour-based access controls block or challenge a session?
• Who is accountable when a contractor still has privileged cloud access after departure?
• Who is accountable when a password manager is used to store privileged access credentials?