Accountability should sit with the AD or IAM team that owns GPO governance, with shared responsibility from system owners for the affected paths and workloads. Security teams need a clear review process for permissions, inheritance, and script changes. If control ownership is vague, unauthorised modifications are more likely to survive unnoticed.
Why This Matters for Security Teams
A modified GPO logon script is not just a Windows administration issue; it is a privilege and execution-path governance issue. Logon scripts can silently affect every user session, which makes unclear ownership especially dangerous when a change lands outside approval. The control question is less about who typed the edit and more about who is accountable for preventing unauthorised execution.
In practice, the accountable party is usually the AD or IAM team that owns GPO governance, while system owners share responsibility for the workloads and paths affected. That split matters because change approval, inheritance, and downstream execution often cross team boundaries. NIST control language around access enforcement and configuration management reinforces that accountability must be explicit, not implied, in NIST SP 800-53 Rev 5 Security and Privacy Controls. NHIMG research also shows why this matters: Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is the same governance failure pattern that lets unauthorised script changes survive. In practice, many security teams encounter the issue only after a script has already executed at scale, rather than through intentional review.
How It Works in Practice
Operational accountability starts with the GPO owner, not the server owner and not the application team. The AD or IAM function should own the policy object, the linked OU scope, the change workflow, and the rollback path. System owners then approve whether the script’s business effect is acceptable for their endpoints, servers, or user populations. Security’s role is to verify that the change path is logged, that privileged editors are limited, and that inheritance does not reintroduce a path around review.
The practical control set usually includes:
- restricted write access to GPO objects and script locations
- separate approval for script content, link changes, and inheritance changes
- version control for scripts and policy backups for rollback
- monitoring for changes to separation of duties and privileged admin activity
- review of whether scripts call out to secrets, shares, or other execution dependencies
This is where identity governance and NHI governance overlap. A logon script often runs with effective privileges that exceed the person who changed it, so the real control objective is to bind execution to approved identity and change context. The same ownership logic that applies to service accounts, API keys, and other machine identities in Ultimate Guide to NHIs applies here: make the owner explicit, make the change visible, and make the runtime effect traceable. Current guidance suggests the best evidence is a documented approval trail plus automated detection of direct edits outside the change window. These controls tend to break down when legacy GPOs are edited through ad hoc admin access because inheritance and replication obscure who actually authorised the final version.
Common Variations and Edge Cases
Tighter change control often increases operational overhead, requiring organisations to balance fast remediation against stronger governance. That tradeoff is especially visible when emergency fixes are needed for ransomware containment, login failures, or endpoint rollout issues. In those cases, best practice is evolving toward time-boxed emergency access with mandatory post-change review, rather than relying on informal after-the-fact sign-off.
There is no universal standard for this yet, but the accountable owner should still be the team responsible for the policy object and its approval workflow. If a security team centrally manages GPOs, then it may also inherit accountability for unauthorised edits. If application teams own the script content but AD owns the policy link, accountability should be split by control plane: content owner for what the script does, GPO owner for where and how it is executed. This distinction is important when scripts reference external shares, mapped drives, or credential stores, because the blast radius is broader than the GPO itself.
Where organisations struggle most is in shared admin models and poorly documented inheritance. Those environments make it easy to say “someone else owned it,” which is exactly how unauthorised modifications persist. Explicit RACI, change tickets, and access reviews are the practical answer, not informal agreement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Unauthorized script edits often reflect weak control over non-human execution paths. |
| NIST CSF 2.0 | PR.AC-4 | Access governance is central when changes to GPO scripts bypass approval. |
| NIST AI RMF | Accountability and oversight are core to governing automated execution paths. | |
| NIST Zero Trust (SP 800-207) | ID | Zero trust demands explicit identity and policy enforcement for admin actions. |
Assign ownership and review of all machine-executed scripts, secrets, and service paths to named control owners.
Related resources from NHI Mgmt Group
- What breaks when organisations launch AI systems without formal risk assessment and approval workflows?
- Who is accountable when an API is exposed without adequate discoverability and governance?
- Who is accountable when a high-risk SaaS or AI tool is used without documented purpose or review?
- Who is accountable when a decoy certificate template is modified and an alert fires?
