Who should be accountable for closing access-trust gaps across BYOD, shadow IT, and unmanaged applications?

Accountability should sit with security and IAM leadership, supported by IT, endpoint, and governance teams. The organisation needs a shared control model for device trust, application approval, and access policy enforcement. Without clear ownership, gaps between teams allow unapproved access paths to persist and make Zero Trust harder to operationalise.

Why This Matters for Security Teams

BYOD, shadow IT, and unmanaged applications create access-trust gaps because no single team owns the full chain from device posture to application approval to policy enforcement. Security may define the control intent, IAM may set access rules, IT may manage endpoints, and governance may approve exceptions, but without shared accountability those controls drift apart. The result is predictable: users gain access through paths that were never reviewed as a system.

This is not just an operational nuisance. The Ultimate Guide to NHIs notes that 90% of IT leaders say properly managing NHIs is essential for successful zero-trust implementation, which reflects the same core issue seen in access-trust programs: identity controls fail when ownership is fragmented. The problem is reinforced in the Top 10 NHI Issues, where unmanaged credentials and excessive privilege repeatedly show up as control gaps.

Current guidance from the NIST Cybersecurity Framework 2.0 points toward clear governance and ownership, but many organisations still treat these issues as isolated IT tickets rather than enterprise risk. In practice, many security teams encounter access-trust failures only after an unapproved app or unmanaged device has already been used to reach sensitive systems, rather than through intentional control design.

How It Works in Practice

Accountability works best when it is assigned at the control-system level, not just the ticket level. Security and IAM leadership should own the policy model, while IT, endpoint, application, and governance teams each own a defined part of enforcement. That means one team defines device trust requirements, another validates application approval status, and IAM enforces whether the request is allowed at runtime. The key is that no team can claim the gap is outside its scope.

A practical operating model usually includes three layers:

• Device trust: confirm whether the endpoint is managed, healthy, and eligible for access.
• Application trust: classify whether the app is sanctioned, monitored, and integrated into access policy.
• Access policy: enforce conditional access, MFA, and step-up controls based on risk and context.

The NIST Cybersecurity Framework 2.0 is useful for structuring this as an enterprise governance problem, while NIST SP 800-53 Rev. 5 supports the control expectations behind access restriction, monitoring, and configuration management. For NHI-related access paths, the Ultimate Guide to NHIs ties governance to lifecycle discipline, which is the same operational pattern needed here: define the owner, define the approval path, and define the revocation path before access is granted.

Where organisations get traction is by using a shared exception process, a unified inventory of managed and unmanaged assets, and periodic reviews that force every exception to expire. These controls tend to break down when shadow IT is embedded in business-critical workflows because the business team demands speed while security and IAM inherit responsibility without authority.

Common Variations and Edge Cases

Tighter access control often increases friction, requiring organisations to balance user productivity against the need to close unmanaged access paths. That tradeoff is especially visible in environments with contractors, bring-your-own-device programmes, or fast-moving SaaS adoption, where rigid approval gates can drive more shadow IT instead of less.

Best practice is evolving around shared ownership, but there is no universal standard for this yet. Some organisations place primary accountability with security, with IAM as the control operator and IT as the asset custodian. Others assign the business application owner as the approver for sanctioned tools, while central security retains final policy authority. The important point is that accountability must be explicit, documented, and auditable.

NHIMG research shows the stakes are not theoretical: only 5.7% of organisations have full visibility into their service accounts, and 68% do not know how to fully address NHI risks. That visibility gap is a strong warning for unmanaged app and BYOD governance too, because access cannot be trusted if the organisation cannot inventory the assets and identities involved. For a deeper governance lens, see the Ultimate Guide to NHIs and the NHI Lifecycle Management Guide.

In practice, the most resilient model is not a single owner for every decision, but a single accountable authority for closing the gaps end to end.

Related resources from NHI Mgmt Group

• Who is accountable when unmanaged certificates or shadow PKI create trust gaps?
• Who is accountable when SAP access risks are not governed consistently across cloud and on premises systems?
• Who should be accountable for non-employee access governance across healthcare onboarding teams?
• Who is accountable when access request approvals and audit evidence are spread across multiple teams?