Who is accountable for authorization in a self-hosted deployment?

Why This Matters for Security Teams

Accountability for authorization does not disappear when the stack is self-hosted. The organisation that chooses the deployment model still owns policy design, access decisions, monitoring, and evidence when something goes wrong. That distinction matters because authorization failures in NHI and agentic systems are often treated as “platform issues” until they become audit findings, privilege abuse, or incident-response gaps. NHI Management Group notes that 97% of NHIs carry excessive privileges, which is a strong sign that entitlement governance, not just infrastructure uptime, is the real control problem in many environments, as covered in the Ultimate Guide to NHIs.

For security teams, the practical risk is that self-hosting can blur ownership across platform, application, and compliance functions. When authorization is externalized to a vendor, teams may assume the vendor is responsible for outcomes; when it is self-hosted, they may assume the tool itself “covers” governance. Neither assumption holds. The accountability model must be explicit, especially for environments that map to NIST Cybersecurity Framework 2.0 functions for protect, detect, respond, and recover. In practice, many security teams encounter authorization breakdowns only after a privileged workflow has already been abused, rather than through intentional design review.

How It Works in Practice

In a self-hosted deployment, the organisation is accountable for the authorization service as a control plane, even if a vendor supplies the software. That means the team operating the environment must define who can approve access, how policies are written, how changes are tested, and how exceptions are tracked. The operational owner also needs to preserve logs, retain approval evidence, and ensure the service remains available during incidents and maintenance windows. This is where “who runs it” and “who is accountable for the control” are not the same question.

In practice, mature teams separate responsibility into a few layers:

• Policy ownership: security or platform governance defines the rules, including RBAC, JIT, and exception handling.

• Service operation: infrastructure or SRE teams maintain uptime, patching, backups, and recovery procedures.

• Decision evidence: compliance and audit functions verify that authorization decisions are logged and reviewable.

• Access review: application or identity owners validate that entitlements still match business need.

This is especially important for NHI workloads, where service accounts, API keys, and agent credentials can behave differently from human identities. If the deployment supports workload identity or policy-as-code, the organisation still owns the runtime decisions and their risk posture. The governance challenge is not just whether a system exists, but whether it can prove that access was granted for the right reason at the right time, a theme also reflected in the Ultimate Guide to NHIs. Current guidance suggests treating the authorization layer as a first-class production control, not a configuration detail. These controls tend to break down when ownership is split across teams that do not share incident, evidence, and policy responsibilities because no single group can prove control effectiveness end to end.

Common Variations and Edge Cases

Tighter authorization governance often increases operational overhead, requiring organisations to balance control assurance against deployment speed and support burden. That tradeoff becomes sharper in self-hosted environments because the team must manage every dependency, from patch cadence to failover testing, without relying on the vendor’s managed service posture.

There is no universal standard for this yet, but current guidance suggests the accountability model should change only when a contractual or regulatory framework explicitly transfers responsibility, and even then the organisation usually retains residual oversight. For example, a third-party integrator may operate the platform, but the business still owns risk acceptance, access policy, and evidence retention. This is particularly relevant where NHIs are exposed to third parties or where long-lived secrets are in use; the operational burden grows quickly when approvals, revocation, and audit trails are handled manually.

Best practice is evolving toward a documented RACI that names the system owner, the policy owner, the technical operator, and the approver chain. That model should also define who can suspend access during an incident and who must preserve records for audits or investigations. In environments with high turnover, multi-region deployments, or shared administrative teams, ambiguity usually shows up first as delayed revocation or missing evidence after a security event.

Related resources from NHI Mgmt Group

• Who should be accountable for Cloudflare changes that affect production traffic?
• Who is accountable when a manipulated identity authorises a major crypto transfer?
• What do security and compliance teams get wrong about self-service transfer setup?
• Who is accountable when a regulated transfer workflow fails audit review?