Windows Enterprise Release Platform

Use this guide to deploy and validate the official Windows release pathway for thoth.exe and thothctl.exe.

Distribution architecture

Windows releases are published as:

• raw signed binaries (thoth.exe, thothctl.exe)
• signed MSI installer (Thoth-x64.msi)
• Intune deployment kit (Intune-Deployment-Kit.zip)
• integrity and provenance metadata

Recommended release source:

• GitHub Releases in atensecurity/thoth

Recommended enterprise deployment channel:

• Intune Win32 MSI deployment (primary)

Packaging strategy

Installer technology:

• WiX Toolset v5 MSI (primary and recommended)

Why WiX MSI:

• native Windows enterprise deployment compatibility
• first-class Intune support
• deterministic, source-controlled installer definitions
• strong upgrade/uninstall behavior for managed fleets

Install path:

• C:\Program Files\Aten Security\Thoth\

Installer behavior:

• installs thoth.exe and thothctl.exe
• updates system PATH for CLI access
• supports silent install and uninstall
• supports major upgrades
• preserves C:\ProgramData\Aten Security\Thoth for config continuity

Authenticode strategy

Baseline production strategy:

1. Sign thoth.exe, thothctl.exe, and Thoth-x64.msi with Authenticode.
2. Timestamp every signature.
3. Verify signatures in CI before publish.

Certificate model recommendation for 2026:

1. Preferred: Azure Trusted Signing with OIDC federation (reduce long-lived key custody risk).
2. Interim: EV code-signing certificate in HSM-backed custody with strict access controls.
3. Avoid: unmanaged local private-key workflows.

SmartScreen expectations:

• Early signed releases may still show reputation warnings.
• Reputation improves with consistent signed distribution and low abuse signals.
• EV-backed signing generally improves initial trust posture but does not eliminate all warnings immediately.

Enterprise release artifacts

Each Windows release publishes:

• thoth.exe
• thothctl.exe
• Thoth-x64.msi
• SHA256SUMS
• SBOM-CycloneDX.json
• SBOM-SPDX.json
• provenance.json
• artifact-attestation.json
• release-metadata.json

Additional enterprise artifacts:

• Intune-Deployment-Kit.zip
• windows-signing-metadata.json
• *.sig and *.sigstore.json bundles for keyless verification

Verification workflow (security teams)

Download release assets from matching tag and run:

sha256sum -c SHA256SUMS
jq -e '.provenanceType == "release-artifact-provenance"' provenance.json
jq -e '.bomFormat == "CycloneDX"' SBOM-CycloneDX.json
jq -e '.spdxVersion | startswith("SPDX-")' SBOM-SPDX.json

Optional GitHub attestation verification:

gh attestation verify SHA256SUMS --repo atensec/maat

Sigstore bundle verification example:

cosign verify-blob \
  --bundle Thoth-x64.msi.sigstore.json \
  Thoth-x64.msi

Intune deployment model

Use Intune Win32 app deployment with MSI + detection script:

• install command: msiexec /i Thoth-x64.msi /qn /norestart ALLUSERS=1
• uninstall command: msiexec /x {PRODUCT-CODE} /qn /norestart
• detection: detect-thoth.ps1 from Intune deployment kit

Recommended rollout rings:

1. Test ring (1-5 devices)
2. Pilot ring (5-15% of fleet)
3. Production ring (remaining fleet)

Gate progression on:

• install success rate
• health check stability
• no unexpected SmartScreen or execution blocks

Winget position

Winget is treated as a secondary developer channel.

Policy recommendation:

• keep Winget manifest generation automated
• keep Winget submission as approval-gated/manual until enterprise MSI channel is stable

Related docs

• Intune Windows Runbook
• Release Channels + Verification
• Deployment Validation Matrix