The question every application control project eventually faces
At some point in every WDAC rollout, someone asks the question that decides whether the project survives contact with the business:
"How do you handle the scripts our own admins need to run?"
It is a fair question. Internal PowerShell, deployment scripts, Office macros the finance team has relied on for years, one-off remediation tooling written the morning an incident started. None of it is signed by a vendor. Under enforced application control, none of it runs.
The instinct is to reach for an exception. That instinct is the problem.
Why the exception is the wrong answer
Application control blocks unsigned code because unsigned code is one of the most common ways malicious code reaches a workstation. That is not a limitation of WDAC. It is the entire point.
The moment you carve out a path for unsigned internal scripts, you have reopened the door you spent the project closing. A hash rule for one script becomes a folder rule for a share. A folder rule becomes a writable location every user can drop a payload into. The policy still says "enforced," but the meaning has drained out of it.
The alternatives teams usually reach for are all bad in their own way:
— allow the unsigned internal code, and you have accepted the risk you were paid to remove
— block it, and you have broken the business and lost the room
— review every script by hand, and you have built a queue your security team will never clear
The correct answer is none of these. The correct answer is that internal code should be signed, the same way vendor code is signed, before it is trusted.
Signing is the mechanism application control was built around
WDAC's strongest rule type is the publisher rule. Trust a certificate, and every file signed by it is allowed without a hash rule, without a path rule, without policy bloat. This is why publisher rules are the backbone of a clean policy and why a policy built purely from audit events ends up bloated and brittle.
Vendor code arrives already signed, so it slots into this model naturally. Internal code does not, because nobody signs it. That is the whole gap. Close the gap, and internal scripting stops being an exception problem and becomes a normal part of your trusted-publisher policy.
So the real question is not "how do we make an exception for internal scripts." It is "how do we get internal scripts signed, safely, at the speed the business actually works."
What a signing pipeline has to solve
Handing developers and admins a code-signing certificate does not solve it. That just moves the door. Now anyone with the certificate can sign anything, including the malicious script they were tricked into running, and your trusted publisher is only as trustworthy as the least careful person holding the key.
A signing pipeline that actually works has to do three things:
— assess the file before it is signed, so that what gets trusted has been shown to be safe rather than merely convenient
— keep the signing key out of human hands, so trust comes from the pipeline and not from whoever holds a certificate
— record every sign-or-reject decision, so an assessor can see exactly how a given script earned its signature
That is the shape of the problem. Assessment, custody, evidence. Get those three right and internal scripting is no longer the weak point of your application control programme.
Assessment is where the difficulty actually lives
Deciding whether a script is safe to sign is not trivial, and single-method checking is where most attempts fall down. Detonating a file in a sandbox catches code that misbehaves when it runs, but sophisticated code stays dormant the moment it senses a sandbox and runs its payload later. Reading the source catches dormant and time-delayed logic and source written to mislead, but static analysis alone misses behaviour that only appears at runtime.
Neither method is sufficient alone. One method's blind spot is the other's strength, which is why serious assessment uses both, and why anything short of a conclusively clean result should be held for a human rather than signed on a guess. A confirmed malicious result should never be overridable.
This is deliberately more work than an admin clicking "allow." That is the point. The friction sits in the pipeline, once, instead of sitting in your policy forever.
This is a framework requirement, not a nice-to-have
Controls on Office macros and executable code are written into the Australian frameworks you are assessed against. The Essential Eight treats application control and macro control as distinct mitigation strategies, and the maturity model expects both to hold under evidence. The PSPF, the ADHA framework for health, and the AESCSF for the energy sector all carry obligations in the same territory.
An assessor at Maturity Level 3 does not accept "we trust our admins." They ask how each macro and script was vetted before it was allowed to run, and they expect a file-by-file answer. A signing pipeline with a recorded decision at every step produces exactly that evidence. A policy exception produces a finding.
Where this fits with WDACManager
WDACManager manages the application control side of this problem. It ingests execution telemetry, turns it into deployable policy, and keeps that policy clean and versioned as your environment evolves, including the publisher rules that make signed internal code trusted without policy bloat.
The signing side is a companion capability. This is the gap OrgSeal is built to close: a self-service portal that assesses macros, PowerShell, and executables through two independent stages of analysis, signs only the files proven clean, and logs every decision for audit. An admin uploads a script, the pipeline vets it, and a signed file comes back ready to run under a trusted-publisher policy your WDAC deployment already enforces. No exception. No writable-path rule. No certificate handed to a person.
Application control decides what is trusted. A signing pipeline decides how internal code earns that trust. You need both, and they need to fit together.
What to ask your team
- when an admin needs to run an internal script under enforcement, what is the actual process, and does it involve a policy exception?
- who holds our code-signing certificate, and what stops them signing something malicious?
- can we show an assessor, file by file, how each internal script was vetted before it was trusted?
If the honest answer to the first question is "we make an exception," you do not have an application control programme yet. You have one with a hole in it, in the exact shape of your own admins.