Who is accountable when custom identity logic changes access decisions or provisioning outcomes?

Why This Matters for Security Teams

When custom identity logic changes access decisions, the risk is not just misconfiguration. It is delegated control over who can get credentials, what gets provisioned, and when sensitive workflows fire. That makes the identity platform part policy engine, part enforcement point, and part application code base. The organisation operating the platform remains accountable, even if the logic was written by a different team or embedded in an integration.

This is why governance for custom rules must be treated like code governance, not a one-time admin review. Versioning, peer approval, audit trails, test coverage, and rollback need to exist before production use. NHIMG’s Ultimate Guide to NHIs shows how weak lifecycle controls and excessive privileges create lasting exposure, while the OWASP Non-Human Identity Top 10 frames the same issue as a governance failure, not a pure tooling problem.

In practice, many security teams discover broken entitlement logic only after a bad approval path, over-provisioned service account, or failed revocation has already reached production.

How It Works in Practice

Accountability should be assigned across three layers. First, the platform owner is responsible for the control environment: logging, access boundaries, deployment approvals, and safe rollback. Second, the workflow owner is responsible for the business logic: what condition grants access, what trigger provisions a secret, and what exception paths exist. Third, the approver or change authority is responsible for validating that the logic matches policy intent.

In mature environments, custom identity logic should be handled like application code. That means code review, ticketed change management, test fixtures for edge cases, and evidence that the rule behaves correctly before it touches production identities. Where the logic changes provisioning outcomes, the review should include security, IAM, and the system owner. Where it changes access decisions, it should also align to least privilege and documented policy intent.

Current guidance suggests using separation of duties between rule authors and rule approvers, because a single person who can write and release identity logic can silently widen access. NIST control families in NIST SP 800-53 Rev 5 Security and Privacy Controls support this pattern through access control, audit, and change-related safeguards. NHIMG’s Lifecycle Processes for Managing NHIs reinforces that provisioning and revocation must be controlled from creation to offboarding, not handled as informal scripting.

• Version every custom rule and tie it to an owner, approver, and release window.
• Test provisioning and denial paths before promotion, including failure and rollback cases.
• Log rule evaluation, not only the final access outcome, so auditors can see why a decision was made.
• Require emergency changes to be time-bound and reviewed after the incident is contained.

These controls tend to break down when identity logic is embedded in CI/CD pipelines or low-code automation without a separate review gate, because changes can ship faster than oversight.

Common Variations and Edge Cases

Tighter control over identity logic often increases operational overhead, requiring organisations to balance release speed against the risk of hidden privilege changes. That tradeoff becomes sharper when teams use low-code workflow builders, custom scripts, or event-driven provisioning, because the line between configuration and code is easy to blur.

There is no universal standard for this yet, but current guidance suggests the same accountability model should apply whether the logic lives in policy-as-code, a webhook, or a provisioning script. If a change can alter access, revoke credentials, or trigger sensitive actions, it deserves the same governance as any other production control. This is especially important where NHIs are already overexposed, as NHIMG notes in the Top 10 NHI Issues.

One practical edge case is vendor-managed identity orchestration. The vendor may operate the tooling, but accountability still sits with the organisation that approves the logic and allows it to run in production. Another edge case is emergency break-glass logic, which may bypass normal approval flow but should still be time-limited, logged, and reviewed after use. In both cases, the question is not who wrote the code. It is who accepted the risk of letting that code influence identity outcomes.

Related resources from NHI Mgmt Group

• Who should be accountable for securing disconnected applications when access is managed through custom API automation?
• What breaks when identity data and access decisions are not kept current across internal and external ecosystems?
• Who is accountable when malicious identity changes affect compliance evidence in AD and Azure AD?
• Who should be accountable for reducing access risk across the full identity stack?