Who is accountable for authorization policy when using a third-party service?

Why This Matters for Security Teams

Third-party services often create a false sense of delegated control: the provider may host the system, but it does not inherit the organisation’s duty to define who can do what, under which conditions, and with what evidence. That distinction matters because authorization policy is where business intent becomes enforceable security. When the policy is vague, overbroad, or left to default settings, the result is usually excessive access, weak auditability, and inconsistent enforcement across environments.

This risk is especially visible in NHI-heavy systems, where secrets, tokens, service accounts, and API clients are already difficult to govern. NHIMG notes that 92% of organisations expose NHIs to third parties, which makes supplier-bound workflows a common supply chain exposure point. In practice, the hard part is not whether a vendor can run the platform, but whether the organisation can prove that policy decisions still align with internal risk tolerance and compliance requirements, as reflected in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.

In practice, many security teams discover policy drift only after a third-party integration has already expanded access beyond what the business intended.

How It Works in Practice

Accountability starts with ownership of the policy model. The organisation should define the authorization rules, approve exceptions, and specify which identities, actions, resources, and contexts are in scope. A vendor may provide tooling, but the security team still needs to decide whether access is role-based, attribute-based, or context-aware, and whether enforcement must happen at request time or through pre-approved entitlements. For third-party services, that means the organisation should keep control of policy-as-code, review the policy surface during procurement, and demand audit logs that show what was allowed, denied, and changed.

For NHI and service-to-service access, current guidance suggests treating the third-party service as a control plane, not as the policy owner. That usually means short-lived credentials, explicit approval workflows, and tight integration with identity governance. The most reliable pattern is to bind policy to workload identity and task context, then verify the decision against business rules before tokens or secrets are issued. This is consistent with the NIST SP 800-53 Rev. 5 Security and Privacy Controls approach to access control and the NIST Cybersecurity Framework 2.0 emphasis on governance and accountability.

• Define the policy, approval chain, and review cadence internally.
• Require vendor APIs to expose change history and enforcement logs.
• Use least privilege for every third-party connector and NHI.
• Reassess delegated access whenever scopes, tenants, or integrations change.

NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which explains why delegated authorization often looks controlled on paper but is not operationally verifiable in practice; see the 52 NHI breaches Analysis and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives.

These controls tend to break down when the third-party service chains multiple downstream tools because the original approval boundary becomes fragmented across systems.

Common Variations and Edge Cases

Tighter third-party control often increases integration overhead, requiring organisations to balance speed of deployment against governance depth. That tradeoff is most visible when the vendor offers managed authorization features, because convenience can blur responsibility if internal owners assume the platform’s defaults are sufficient.

There is no universal standard for this yet, but current guidance suggests the same core rule: the provider can enforce, automate, and evidence policy, but it should not be the final authority on what access is acceptable. In federated environments, the organisation may allow the vendor to host policy engines while still retaining policy authorship, approval rights, and exception handling. In regulated use cases, especially where API access touches customer data or production systems, audit teams should insist on separate ownership of policy definition, policy deployment, and policy attestation.

One common edge case is shared responsibility in marketplace integrations, where both the platform owner and the customer can alter access scopes. Another is reseller or MSP-managed environments, where delegation is contractual but accountability remains with the customer unless obligations are explicitly transferred. For supplier-heavy NHI estates, the safest interpretation is simple: if the organisation can be harmed by the access decision, it must own the decision. That operational reality aligns with the Top 10 NHI Issues and the OWASP framework’s focus on non-human authorization failures.

Related resources from NHI Mgmt Group

• Who is accountable for PCI SAQ compliance when organisations rely on third-party payment providers?
• Who is accountable for access decisions when third-party integrations and AI agents share business systems?
• Who is accountable for OAuth governance when third-party apps and AI tools keep access to sensitive data?
• Who is accountable when third-party or service access is still routed through a VPN?