Who is accountable when IAM complexity is pushed into custom code and scripts?

Why This Matters for Security Teams

When IAM complexity is pushed into custom code and scripts, accountability often becomes diffused across the teams that wrote, approved, deployed, and now have to maintain it. That is where failures become hard to trace: the identity platform team may own the baseline controls, application teams may own the script logic, and infrastructure teams may own the runtime environment, but no single owner is clearly accountable for the full control path. The result is slower remediation, hidden exceptions, and identity debt that accumulates outside normal governance. NHIMG research shows that 30.9% of organisations store long-term credentials directly in code, which is exactly the kind of practice that turns a temporary workaround into a persistent risk pattern. It is also why controls like Azure Key Vault privilege escalation exposure matter: custom logic can quietly widen access instead of constraining it. In practice, many security teams only discover who was accountable after a script has already failed, exposed secrets, or bypassed the intended approval flow.

How It Works in Practice

Accountability should follow the control boundary, not the convenience boundary. If a team writes custom code to provision identities, rotate secrets, or grant access, that team becomes accountable for the correctness, logging, testing, and rollback of that logic. IAM still owns the platform guardrails, but application and infrastructure owners must own the code that changes identity state. The cleanest operating model is to make the identity platform configurable first, then use scripts only for exceptions that are documented, reviewed, and monitored.

Practitioners usually separate responsibilities into three layers:

• Platform ownership: the IAM team defines approved patterns, policy constraints, and audit expectations.
• Application ownership: the service owner approves the business requirement and validates that the automation matches the intended access model.
• Runtime ownership: the infrastructure or platform team ensures scripts run in controlled environments with secrets management, traceable logs, and rollback paths.

This is consistent with the direction of NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects organisations to assign clear responsibility for access control, configuration management, and auditability. It also aligns with NHIMG guidance in the Ultimate Guide to NHIs, especially where scripted identity workflows can create untracked privilege and weak offboarding. The practical test is simple: if the script can create access, it must be treated like a control and governed like one. These controls tend to break down when scripts are embedded in CI/CD pipelines with no named owner, because changes can ship faster than review and the resulting access drift is hard to reverse.

Common Variations and Edge Cases

Tighter governance often increases delivery overhead, so organisations must balance speed against the cost of unmanaged exception handling. That tradeoff becomes sharper in legacy environments, hybrid estates, and vendor platforms that do not expose the identity controls teams need. In those cases, custom code may be unavoidable, but current guidance suggests treating it as a temporary bridge rather than a default architecture.

Two edge cases appear frequently. First, a central IAM team may approve the pattern but not the implementation. That is not enough: the team that owns the script still owns its failure modes. Second, shared automation across multiple applications can blur accountability even further. The fix is to name a single control owner, document the business purpose, and require explicit change management for every logic path that can grant, revoke, or modify access.

NHIMG’s reporting also shows how quickly technical debt turns into exposure when identity workarounds are left in place. If a workaround touches secrets, access tokens, or service accounts, the organisation should assume the risk extends beyond the script itself to the surrounding lifecycle. TruffleNet BEC Attack — Stolen AWS Credentials is a useful reminder that poor identity handling can become an incident multiplier, not just an administrative inconvenience. There is no universal standard for this yet, but best practice is evolving toward explicit ownership, policy-as-code, and reducing custom identity logic wherever the platform can support it.

Related resources from NHI Mgmt Group

• Who should be accountable when access decisions in Django span both application code and an external policy layer?
• What is the difference between code scanning and runtime identity monitoring?
• What breaks when IAM relies on manual intervention and custom scripts to enforce policy?
• How should security teams implement try-catch patterns in PowerShell for unattended administrative scripts?