When should organisations still use scripting instead of configuration in identity workflows?

Why This Matters for Security Teams

Identity workflows often look simple until they touch exceptions, legacy systems, or fast-moving remediation. That is where scripting earns its place: not as a default, but as a controlled way to express logic that configuration cannot model cleanly. For security teams, the real issue is avoiding a brittle mix of manual workarounds and hidden automation that no one reviews.

The risk is not scripting itself, but unmanaged scripting. Hard-coded secrets, opaque branching logic, and privileged API calls can turn a small identity workflow into an incident path. NHIMG’s Ultimate Guide to NHIs notes that 30.9% of organisations store long-term credentials directly in code, and 79% have experienced secrets leaks. That is why scripting must be treated as governed automation, not developer convenience. The same pattern shows up in real breach analysis, including the 52 NHI Breaches Analysis, where weak secret handling and overbroad access often start in “temporary” logic that later becomes permanent.

In practice, many security teams encounter this only after a one-off script has quietly become the system of record for critical identity changes.

How It Works in Practice

The practical decision point is whether the workflow can be represented safely as configuration, or whether it needs executable logic to handle data shaping, conditional routing, or exception handling. Configuration is best for repeatable, low-variance processes such as standard joiner-mover-leaver steps, attribute mapping, and policy-driven approvals. Scripting is justified when the workflow must transform inputs, call multiple systems, or make decisions that depend on context not available in a static rule set.

A secure pattern is to keep the script narrow and observable. Use configuration for the normal path, then let the script handle only the exceptional branch. Where possible, bind the script to a NIST Cybersecurity Framework 2.0 control objective such as change management, access control, and logging. That means version control, peer review, test coverage, and explicit ownership. It also means avoiding embedded credentials and using short-lived secrets or workload identity wherever the workflow touches external services. NHIMG’s Top 10 NHI Issues highlights how quickly identity automation becomes a risk when secrets are stored outside managed controls.

• Use configuration when the workflow is stable, auditable, and easy to model.
• Use scripting when transformations, special integrations, or exception paths are too complex for configuration.
• Limit script scope to one job, one owner, and one clear rollback path.
• Review scripts like code, including dependency checks and secret scanning.

The operational test is simple: if the logic can be explained and maintained without custom execution, configuration wins; if not, scripting can be safer than forcing the wrong tool. These controls tend to break down when scripts are copied into multiple identity platforms because the same exception logic then fragments across environments.

Common Variations and Edge Cases

Tighter control over scripting often increases delivery time and review overhead, requiring organisations to balance agility against auditability. That tradeoff is real in hybrid estates, where one identity platform supports rich configuration and another exposes only limited workflow hooks. In those environments, the best practice is evolving rather than settled: some teams standardise on configuration-first and allow approved scripts only for exceptions, while others permit scripting more broadly but wrap it in policy, testing, and secrets governance.

Edge cases usually appear in remediation, migration, and integration work. A script may be justified for temporary backfills, cross-directory reconciliation, or compensating controls when a vendor connector cannot express the needed logic. The danger is permanence. Temporary scripts often survive long after the original problem disappears, which is why change tickets should include a removal date and a review trigger. NHIMG’s Code Formatting Tools Credential Leaks is a useful reminder that automation can leak secrets through unexpected paths, especially when scripts are edited, shared, or reused across teams.

Current guidance suggests treating scripting as an exception pathway, not an identity design pattern. When the workflow becomes reusable and predictable, convert it back into configuration so the control surface stays smaller and the review burden stays lower.

Related resources from NHI Mgmt Group

• How should organisations decide when to use passkeys versus digital identity credentials?
• How should organisations use SOC 2 Type II evidence when evaluating IAM and identity governance providers?
• Why do large organisations struggle to onboard business applications into identity security workflows?
• How should organisations enforce identity governance across multi-cloud and AI-driven workflows?