Skip to main content
Version: 2026.08

Trusting the Windows installers

Windows decides whether to run the Istari Digital Agent installer using two independent mechanisms, and they fail in ways that look alike. Authenticode asks whether the file is validly signed, by whom. Reputation and application control — SmartScreen, Windows Defender Application Control (WDAC), AppLocker — ask whether this particular file is allowed to run here, and a valid signature does not by itself answer that.

This page is for the Windows or security team that manages the host. It covers how the packages are signed and how to verify that yourself, how to tell the two mechanisms apart from the dialog on screen, why a correctly signed installer still draws a SmartScreen warning on every new release, and the three ways to admit Istari Digital software to a managed fleet: delivering it without the Mark of the Web, allow-listing by publisher, and adding the signing certificate to Trusted Publishers. Only the first is untouched by our per-release certificate reissue: a Trusted Publishers entry has to be refreshed every release, and a WDAC publisher rule needs attention whenever Microsoft rotates its issuing intermediates. This page explains both.

If you are installing on a single unmanaged machine, Agent Installation is the page you want; come back here only if Windows refuses the installer.

How the packages are signed​

Every Windows executable and every MSI in an agent release is Authenticode-signed through Artifact Signing (formerly Trusted Signing), Microsoft's managed signing service:

PropertyValue
Signer subjectCN="Istari Digital, Inc", O="Istari Digital, Inc", L=Arlington, S=District of Columbia, C=US
IssuerOne of Microsoft's Microsoft ID Verified CS ... CA nn intermediates, for example CN=Microsoft ID Verified CS EOC CA 03, O=Microsoft Corporation, C=US
Certificate chainIstari Digital → that Microsoft-operated intermediate → Microsoft Identity Verification Root CA 2020
Digest algorithmSHA-256
TimestampRFC 3161 countersignature from timestamp.acs.microsoft.com

Two things about that subject are worth knowing before you compare it to what you see. The CN value is quoted — CN="Istari Digital, Inc" — because the value itself contains a comma, which would otherwise read as a separator between relative distinguished names. And the O, L, S, and C components follow it. An exact match against a bare CN=Istari Digital, Inc will fail on both counts.

For that reason, match on CN and O rather than on the whole distinguished name. The L and S components would change if the company address did, and the leaf's thumbprint is reissued with every release, so a thumbprint identifies one artifact rather than identifying us. The issuer is the more stable thing to check if you want the chain confirmed — though note that the trailing CA number rotates, which matters when you write application-control rules; see Allow-list Istari Digital by publisher.

The signing certificate is short-lived on purpose. Artifact Signing issues a certificate valid for about 72 hours and reissues it for each release, so the certificate that signed any release older than a few days has already expired. This is by design and does not invalidate anything: the RFC 3161 countersignature proves the file was signed while the certificate was valid, which is what keeps the signature good afterwards.

A worked example, since this is the detail that most often gets escalated. Agent 11.11.2 was released on 2026-08-25; its certificate was valid from 2026-08-24 to 2026-08-27. Checked on 2026-09-21 — nearly a month after the certificate expired — Get-AuthenticodeSignature still reported:

Status        : Valid
StatusMessage : Signature verified.

because the countersignature from Microsoft's timestamping authority was itself still valid. An expired NotAfter is expected, not a finding.

Verify a release yourself​

Run this against the file you are about to deploy:

Get-AuthenticodeSignature .\istari-agent_X.Y.Z_windows-amd64.msi |
  Format-List Status, StatusMessage, SignerCertificate

Status should be Valid. To record the signer for an intake ticket:

$cert = (Get-AuthenticodeSignature .\istari-agent_X.Y.Z_windows-amd64.msi).SignerCertificate
$cert | Format-List Subject, Issuer, Thumbprint, NotBefore, NotAfter

With the Windows SDK available, signtool verify /pa /v .\istari-agent_X.Y.Z_windows-amd64.msi prints the full chain and the countersignature timestamp.

Anything other than Valid needs reading carefully, because the statuses mean different things and only one of them points at your certificate store:

  • NotTrusted means the chain did not build to a trusted root. The usual cause is that Microsoft Identity Verification Root CA 2020 is not present on the host — automatic root updates are frequently turned off on managed or disconnected fleets, and that root is distributed through them. Confirm with certutil -store root and, if it is missing, deploy it to Trusted Root Certification Authorities the same way you deploy your other roots.
  • UnknownError means verification failed for a reason other than an untrusted chain — an invalid or malformed signature is the common case, and it does not narrow things further than that. Either way it is not a missing root, so deploying a root certificate will not fix it and must not be treated as the answer. Re-download and check again; if it persists, treat the artifact as suspect.
  • HashMismatch means the file was altered after signing. NotSigned means there is no signature at all. Neither should happen with a package from the Customer Portal.

In every case other than Valid, do not clear the Mark of the Web and do not install the package; contact support with the status and the file name instead.

Which dialog are you looking at​

The wording tells you which mechanism refused the file, and therefore which fix applies. Reading it wrong sends teams to the wrong remedy.

What the dialog saysMechanismWhat resolves it
"Windows protected your PC" / "prevented an unrecognized app from starting", with More info → Run anywaySmartScreen reputationDeliver without the Mark of the Web, or clear the mark after verifying the signature
The same SmartScreen wording but with no Run anyway optionSmartScreen configured to warn and prevent bypass, by policyMotW-free delivery, so SmartScreen never evaluates the file; otherwise a policy change on your side
"Your organization used Windows Defender Application Control to block this app"WDACA WDAC publisher rule
"This app has been blocked by your system administrator"AppLocker or Software Restriction PoliciesAn AppLocker publisher rule, or an SRP certificate rule
"The system administrator has set policies to prevent this installation"Windows Installer is turned off by policy — unrelated to signingThe Turn off Windows Installer policy, under Host Configuration
UAC offers to run software from an unknown publisherThe signature did not validateVerify it as above — usually an incomplete download or a missing root certificate

Only the first row has a bypass. Low reputation on its own never removes Run anyway, so a refusal with no way through is not about reputation. On a managed fleet it is almost always policy — SmartScreen set to prevent bypass, or application control — and the fix is a policy or delivery change rather than anything about the file. SmartScreen also blocks outright, with no bypass, for a file it has identified as malicious; on a correctly signed release that would be a false positive, so verify the signature first and then use the file submission form in If you are still stuck.

Why a signed installer still warns, on every release​

SmartScreen is a reputation check, not a signature check. Signing is necessary but not sufficient.

Reputation accrues to a specific file, identified by its hash, and more slowly to the publisher identity behind the signature. Every release ships new binaries with new hashes, so a release published this morning has no file reputation yet even though the publisher and the certificate subject have not changed. Two further details keep this from settling on its own:

  • Artifact Signing confers no immediate reputation, and EV certificates stopped granting an automatic SmartScreen bypass in 2024. There is no certificate grade we can buy that removes the warning.
  • Microsoft rotates the intermediate CAs in the Artifact Signing pool between releases, which can re-trigger warnings for a publisher whose reputation is still accumulating.

So expect this on each new release, and treat its return as normal rather than as a signal. A warning on a freshly published release is not evidence of tampering: verify the signature using the commands above, and it will report Valid.

The practical consequence is that reputation is the wrong thing to wait for. SmartScreen only evaluates files that carry the Mark of the Web, so the durable answer is how the installer reaches the machine.

Deliver the installer without the Mark of the Web​

The Mark of the Web (MotW) is a Zone.Identifier alternate data stream recording the zone a file came from. Browsers, mail clients, and anything else that uses the Attachment Execution Service attach it. SmartScreen and several other checks consult it, and a file without it is not evaluated — which is why staging installers internally is the usual answer for a managed fleet.

Channels that do not attach the mark:

  • Configuration Manager, an Intune Win32 app, or MDT. The management agent writes the file in the system context, so nothing marks it. If you run WDAC with Managed Installer configured, a Configuration Manager deployment also authorizes the package by virtue of the channel, with no publisher rule needed.
  • A copy from an internal file share whose host resolves into the Local intranet zone.
  • A copy from removable media or an internal artifact repository reached by a tool that does not route through the Attachment Execution Service.

Verify rather than assume — zone mapping varies between environments. On the staged file:

Get-Item .\istari-agent_X.Y.Z_windows-amd64.msi -Stream Zone.Identifier -ErrorAction SilentlyContinue

No output means no mark. If the stream exists, Get-Content .\istari-agent_X.Y.Z_windows-amd64.msi -Stream Zone.Identifier shows the recorded zone.

When the file already has one​

Verify the signature first, then clear the mark. Clearing it asserts that you know where the file came from, so it belongs after the check in Verify a release yourself, not before it.

Unblock-File .\istari-agent_X.Y.Z_windows-amd64.msi

Properties → Security → Unblock does the same thing for one file, and Remove-Item .\istari-agent_X.Y.Z_windows-amd64.msi -Stream Zone.Identifier removes the stream directly.

Extracting an archive that carries the mark can propagate it to the files inside, so check the extracted MSI rather than the archive you downloaded.

Allow-list Istari Digital by publisher​

Where you already run WDAC or AppLocker, a publisher rule is the rule to write. Publisher rules match the Authenticode signer rather than a location, so they keep working as file names and hashes change from release to release. The alternatives age badly: a hash rule needs replacing every release, and a path rule means keeping a staging directory permanently allowed, which grants more than the publisher rule it stands in for.

AppLocker. Create a New Publisher Rule, browse to the signed file to populate the publisher fields, then widen the scope — leave file version and file name as * so a version bump does not invalidate the rule. Widen product name as well if you want one rule to cover the modules you deploy later: they are signed by the same publisher but carry their own product names, so a rule scoped to the agent's product will not match them. Note that AppLocker keeps separate rule collections, and the agent needs two: a Windows Installer rule for the MSI, and an Executable rule for the agent binaries the MSI installs. An AppLocker publisher rule is derived from the publisher named in the signature rather than from the issuing CA, so it is not exposed to the intermediate rotation that constrains WDAC publisher rules below.

WDAC. Author the rule at the Publisher level, which binds the leaf subject name to the CA that issued it. That is the level to use — FilePublisher additionally pins the file name, and Hash has to be regenerated for every release — but note what it is and is not robust to. A leaf reissued under the same CA still matches, which covers the 72-hour reissue described above. A change of issuing intermediate does not, and Microsoft does rotate the intermediates in the Artifact Signing pool between releases — agent 11.11.2, for instance, was issued under Microsoft ID Verified CS EOC CA 03, and the trailing number and the AOC/EOC element both vary across the pool. So generate the rule from the release you are deploying, confirm it matches before you rely on it, and expect to add a rule if a later release arrives under a different intermediate. Adapt this to your own policy pipeline:

Generate the rule from the installed executables, not from the MSI. WDAC rule generation reads the signature out of a portable executable, and an MSI is not one — it is an OLE compound file, so there is nothing for New-CIPolicyRule to read. Install the agent on one staging machine first, then point the scan at what landed in %LOCALAPPDATA%\istari_agent\:

$rules = New-CIPolicyRule -Level Publisher -DriverFilePath "$env:LOCALAPPDATA\istari_agent\istari_agent_X.Y.Z.exe"
New-CIPolicy -FilePath '.\IstariDigital-Agent.xml' -Rules $rules

Then merge that fragment into your base policy with Merge-CIPolicy and deploy it as you normally would.

That leaves the installer itself to authorize, which WDAC handles differently from the code it installs. Either configure Managed Installer and deploy the MSI through the channel you designated — Configuration Manager, typically — or cover the MSI with an AppLocker Windows Installer rule as above and let WDAC govern the binaries. Do not expect the executable rule to admit the MSI.

Scope the rules to both the installer and what it installs. The MSI runs once; the agent executable in %LOCALAPPDATA%\istari_agent\ runs continuously, and modules the agent loads later are signed the same way.

Add the signing certificate to Trusted Publishers​

The Trusted Publishers store pre-answers "do you trust this publisher?" for the components that consult it — signed PowerShell under an AllSigned execution policy, driver packages, ClickOnce, Office macro trust, and SRP certificate rules. Two limits are worth knowing before you plan around it:

  • It has no effect on SmartScreen, which does not consult the store. It is not a substitute for the delivery change above.
  • AppLocker and WDAC publisher rules read the signature directly and do not require it, so where you have those, the rules in the previous section are the load-bearing part.

The certificate is reissued for each release, which the store does not accommodate well: an entry holding one release's certificate will not match the next one, reproducing exactly the per-release recurrence this page is about. Two ways around that, and the choice is yours to make:

  • Refresh the entry per release, as a step in your software intake. This is the only one of the two that reliably keeps working.
  • Add the issuing intermediate CA instead of the leaf certificate. This covers every release issued under that intermediate, which is not the same as every release: Microsoft rotates the intermediates, so a later release can arrive under a different one and miss the entry. It also extends trust to every other publisher signing under that CA. So it reduces how often you touch the entry rather than removing the need to, and it grants more than it looks like. Weigh both before choosing it.

Export the certificate from the installer you have already verified:

$sig = Get-AuthenticodeSignature .\istari-agent_X.Y.Z_windows-amd64.msi
Export-Certificate -Cert $sig.SignerCertificate -FilePath .\IstariDigital-CodeSigning.cer

Via Group Policy​

In the Group Policy Management Editor, open Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Publishers, then right-click and Import the .cer file. If the machines also lack Microsoft Identity Verification Root CA 2020, import that into Trusted Root Certification Authorities in the same place.

Via Intune​

Intune's Trusted certificate profile writes only to the root and intermediate stores, so it can deliver the root certificate but cannot populate Trusted Publishers. Deploy that one with a platform script instead — Devices → Scripts and remediations → Platform scripts, added as a Windows 10 and later script and run in the system context, not as the signed-in user:

A platform script is uploaded as a single .ps1 with no companion files, and its working directory on the device is not somewhere you can rely on, so the script cannot simply read a .cer sitting next to it. Carry the certificate inside the script instead:

$base64 = '<the .cer file, base64-encoded>'
$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new([Convert]::FromBase64String($base64))
$store = [System.Security.Cryptography.X509Certificates.X509Store]::new('TrustedPublisher', 'LocalMachine')
$store.Open('ReadWrite')
$store.Add($cert)
$store.Close()

This imports from memory rather than writing the certificate to disk first. Do not stage it through a temporary file: the script runs as SYSTEM, %TEMP% for SYSTEM is writable by others on many hosts, and a local user who can replace the file between the write and the import gets a certificate of their choosing into the machine's Trusted Publishers store.

Generate the string with [Convert]::ToBase64String([IO.File]::ReadAllBytes('.\IstariDigital-CodeSigning.cer')). If you would rather not embed it, package the certificate and the script as a Win32 app, which does carry multiple files, or have the script fetch it from an internal location the device can reach.

Validate whichever route you choose on one machine before a fleet-wide rollout, and confirm the agent installs and starts there.

If you are still stuck​

There is one more avenue on the Microsoft side: the Windows Defender Security Intelligence file submission form has an enterprise administrator path that can accelerate trust for an internal or managed deployment. It is worth filing when a release is holding up a rollout, though it is not a substitute for the measures above.

When you contact support@istaridigital.com, include the exact dialog wording, the release and agent version, and the output of the verification command in Verify a release yourself. The dialog wording is the part that identifies the mechanism, and it is the detail most often summarized away.

Next steps​