Windows Download Trust and Evidence-Driven Release Architecture

Full report

On this page

1. Executive Summary and Launch-Blocking Requirements

The deployment of a high-authority application such as LocalEndpoint Connect introduces severe systemic and operational risks that extend far beyond standard desktop software. Because the application is capable of executing arbitrary programs, utilizing network transit, accessing local files, and capturing desktop imagery in an unattended state, traditional claim-based marketing is wholly inadequate. Establishing user trust requires a transition from opaque release processes to verifiable, cryptographically assured evidence models based on stringent supply-chain frameworks. An exhaustive analysis of the current landscape as of July 14, 2026, reveals several critical launch-blocking constraints spanning cryptographic key custody, operating system boundaries, and statutory privacy regulations. These blockers must be structurally mitigated prior to general availability. The foremost technical impediment involves the architectural constraints of the Windows Session 0 isolation boundary. To operate completely unattended, LocalEndpoint Connect must be deployed as a background Windows Service. Beginning with Windows Vista and enforced strictly through Windows 11 and Server 2022, Windows Services are relegated to Session 0, a non-interactive, isolated desktop environment specifically designed to prevent shatter attacks and unauthorized privilege escalation1. Consequently, a service executing in Session 0 is fundamentally prohibited from utilizing graphical APIs to capture the interactive desktop of a locally logged-in user in Session 1 or higher3. The application architecture must be bifurcated: a high-privilege control service running as NT AUTHORITY\\SYSTEM in Session 0, which dynamically spawns and brokers communication with a minimally privileged worker process injected into the active user session to execute screen captures using DXGI or GDI fallback4. The second major blocker involves strict statutory compliance regarding unintended biometric data collection during unattended desktop capture. Under the Illinois Biometric Information Privacy Act (BIPA), capturing facial geometry, voiceprints, or behavioral analytics without prior, explicit written consent carries catastrophic liability, yielding statutory damages of up to $5,000 per reckless violation8. Because the software captures screenshots remotely, the product risks inadvertently collecting biometric identifiers from video calls, identity verification tools, or behavioral patterns present on the target screen9. The release cannot proceed without a mandatory, explicitly documented consent interface that legally indemnifies the operation, establishes a public data destruction policy, and mathematically ensures that captured visual data is never leveraged for secondary commercial profiling11. The third critical blocker involves the compliance mandates enforced by the CA/Browser Forum regarding code-signing certificate lifespans and key custody. As of March 1, 2026, the maximum validity period for publicly trusted code-signing certificates was drastically reduced to 460 days, and the generation and storage of all private keys were strictly mandated to reside within Federal Information Processing Standard (FIPS) 140-2 Level 2 or higher Hardware Security Modules (HSMs)14. The deployment architecture must entirely abandon localized software-based signing keys and adopt an automated, cloud-based cryptographic custody model to maintain continuous release capabilities without manual key ceremonies18. Finally, the release pipeline must achieve a Supply-chain Levels for Software Artifacts (SLSA) v1.0 Level 3 rating. This necessitates the generation of non-falsifiable, machine-readable provenance documents by an ephemeral, hardened build environment20. These documents, alongside comprehensive Software Bill of Materials (SBOM) generation, form the foundation of the public evidence page, aligning the product with the Cybersecurity and Infrastructure Security Agency (CISA) Secure by Design pledges22.

2. Recommended Windows Packaging Strategy

The selection of a deployment packaging format establishes the application’s privilege boundaries, dictates the complexity of enterprise deployment, and shapes the baseline for continuous update mechanisms.

MSIX Limitations and Tradeoffs

Microsoft has heavily promoted the MSIX packaging format for its containerized execution model, reliable uninstallation, and modernized identity APIs25. For many consumer applications, MSIX offers a clean, declarative installation pathway26. However, for a high-authority utility like LocalEndpoint Connect, the MSIX sandbox is inherently antagonistic to the required feature set. To execute arbitrary binaries outside the container, access the broader file system, and interact with the network transparently, an MSIX package must declare the \<rescap:Capability Name="runFullTrust" /\> restricted capability within its manifest27. The declaration of runFullTrust effectively nullifies the isolation benefits of the AppContainer sandbox, rendering the application functionally equivalent to a traditional Win32 executable, while simultaneously subjecting the developer to stringent, time-consuming Microsoft Store onboarding reviews and justifications27. More critically, the MSIX architecture lacks native support for the installation and registration of traditional, background Windows Services required for pre-login, unattended execution. While advanced deployment tools exist to bridge these gaps using Package Support Framework (PSF) fixups, these implementations introduce severe diagnostic opacity and complicate enterprise deployment strategies25.

The Per-Machine MSI Imperative

The recommended deployment strategy for LocalEndpoint Connect is a per-machine Windows Installer (MSI) database, authored using declarative XML schemas via the WiX Toolset30. A per-machine installation (executing in the %ProgramFiles% directory rather than the per-user %LocalAppData% directory) is paramount. Per-user installations operate entirely within the security context of the specific user account and cannot execute if the user is not actively logged into the workstation32. To fulfill the requirement of unattended operation independent of a user session, the MSI must elevate via User Account Control (UAC), copy the binaries to a globally readable location, and register the primary control daemon with the Service Control Manager (SCM) to execute persistently as the LocalSystem account4. Furthermore, an MSI database provides granular control over the installation transaction. It inherently supports headless, silent installations (e.g., msiexec /i package.msi /qn) required for large-scale enterprise deployments via Intune or Microsoft Configuration Manager32. The use of schema-driven generation (such as WiX) ensures that the installer artifact is built deterministically, supporting the integration of cryptographic hashes and minimizing the inclusion of unauthorized or duplicate files within the payload31.

3. Code-Signing and Timestamping Lifecycle

The 2026 code-signing ecosystem requires an automated, infrastructure-as-code approach to key custody and identity attestation. The era of possessing physical USB tokens or locally stored .pfx files in continuous integration environments is obsolete and explicitly violates the updated CA/Browser Forum baseline requirements15.

Certificate Type and Key Custody

The organization must utilize an Organization Validation (OV) Public Trust certificate profile. To achieve absolute compliance with the FIPS 140-2 Level 2+ hardware crypto module mandate without absorbing the overhead of managing physical enterprise HSMs, the project must adopt Azure Trusted Signing (previously known as Azure Artifact Signing)15. Azure Trusted Signing delegates the generation, custody, and lifecycle of the private key entirely to Microsoft's highly secure cloud infrastructure34. The deployment pipeline is granted cryptographic access not by holding a key, but through an Azure Managed Identity or Service Principal assigned the specific "Trusted Signing Certificate Profile Signer" role34.

The Signing Operation

During the final stages of the CI/CD pipeline, the runner does not perform the cryptographic signing locally. Instead, it utilizes the standard Windows signtool.exe augmented with the Azure.CodeSigning.Dlib.dll extension34. The build pipeline authenticates to Azure via environment variables (e.g., AZURE\_CLIENT\_ID, AZURE\_TENANT\_ID), calculates the SHA-256 hash of the MSI, and transmits the hash to the Azure endpoint18. Azure signs the hash using the HSM-backed private key and returns the signed blob, which signtool.exe then embeds into the executable wrapper. This process ensures that the raw binary never leaves the isolated build runner, preserving the integrity of the supply chain while leveraging remote hardware security35.

Timestamp Validation and Ephemeral Certificates

A pivotal architectural shift introduced by Azure Trusted Signing is the utilization of short-lived certificates, typically valid for only a few days34. This minimizes the window of compromise if the authentication mechanisms are breached. However, it necessitates aggressive RFC 3161 timestamping (e.g., against http://timestamp.acs.microsoft.com). By applying a cryptographic timestamp concurrently with the signature, the pipeline guarantees that the signature remains universally valid in perpetuity, long after the ephemeral three-day certificate expires15.

Emergency Revocation

The adoption of a centralized, cloud-brokered identity facilitates rapid incident response. In the event of a suspected pipeline compromise or unauthorized access, the associated Service Principal is immediately disabled in Microsoft Entra ID (formerly Azure AD), instantly revoking the ability to sign new code16. Concurrently, the affected Certificate Profile is suspended, triggering the Certificate Authority to update the Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) responders, immediately invalidating any malicious binaries signed during the breach window19.

4. SmartScreen Analysis and Reputation Management

Establishing trust upon download is heavily hindered by the mechanics of Microsoft Defender SmartScreen. A prevalent misconception within release engineering is that applying a valid digital signature—even from an approved Microsoft CA—guarantees immediate bypass of the "Windows protected your PC" interstitial warning18. SmartScreen relies on an opaque, telemetry-driven reputation model that evaluates the download frequency, the longevity of the publisher identity, and the specific Intermediate Certificate Authority utilized40. In March 2026, Microsoft initiated a silent, automated migration of its Azure Trusted Signing customers from the established EOC CA 02 intermediate authority to a newly minted AOC CA 03 authority41. This rotation instantly decimated the established reputation scores for countless publishers. Binaries that previously downloaded seamlessly began triggering severe SmartScreen blocks solely due to the unrecognized intermediate certificate, despite the underlying publisher identity and code remaining identical41. Consequently, the public launch strategy must vehemently avoid any promises regarding a frictionless, immediate SmartScreen passage. Marketing claims promising "warning-free installation" are indefensible and subject to unpredictable third-party telemetry resets. Instead, the download evidence page must proactively educate the user on exactly what SmartScreen represents: a generalized prevalence filter. The page must provide precise, verifiable instructions directing the user to right-click the installer, navigate to the Digital Signatures tab, and manually authenticate the SHA-256 hash and the "RemoteEndpoints Inc." publisher identity19. By shifting the trust anchor from an opaque reputation algorithm to deterministic cryptographic verification, the product establishes a resilient, evidence-driven public posture.

5. Installer Security and UX Requirements

The MSI package serves as the primary gateway for system modification and must be hardened against tampering and execution failures. To satisfy the requirements of a high-authority installation, the MSI must explicitly prompt for administrative elevation upon launch. The User Account Control (UAC) dialog will display the publisher name pulled directly from the Azure Trusted Signing certificate, providing the user with their first verification of identity. The installer must be engineered to support comprehensive rollback custom actions30. If the installation of the Session 0 service fails, or if the initial configuration of the local environment encounters a permissions boundary, the installer must flawlessly execute a rollback sequence, removing all partially written binaries, configuration files, and registry modifications, returning the system to a perfectly pristine state. Furthermore, to support automated, unattended enterprise deployments, the MSI must support completely silent execution modes (e.g., via the /qn switch)33. This facilitates integration with orchestration tools such as Intune or Ansible, allowing administrators to push the endpoint connector fleet-wide without requiring interactive user input44.

6. Plugin Packaging and Trust Requirements

The application relies on an independent RemoteEndpoints plugin to manage the execution of remotely submitted AI prompts and desktop capture commands. Because these actions occur unattended, without target-side per-prompt approval, the authorization and integrity of the plugin are paramount. The plugin must be distributed as an isolated Dynamic Link Library (DLL) or executable container, cryptographically signed using the same Azure Trusted Signing infrastructure as the primary host application. The host service, executing in Session 0, must enforce a strict runtime allowlist. Before loading the plugin into its privileged memory space, the host application must calculate the SHA-256 hash of the plugin binary on disk and verify that its embedded digital signature chains to an explicitly trusted publisher identity19. This mandatory signature verification nullifies sophisticated supply-chain attacks, such as DLL hijacking or side-loading, where an adversary replaces a legitimate plugin with a malicious payload bearing the same filename25. Furthermore, the initial pairing between the plugin and the user's remote tenant must occur via a time-bounded, cryptographically authenticated handshake, establishing a persistent mutual TLS (mTLS) trust that governs all subsequent unattended commands.

7. Update Architecture

The mechanism utilized to deliver updates to a privileged Windows Service is historically one of the most targeted attack vectors. The architecture must rigidly adhere to The Update Framework (TUF) principles to ensure resilience against man-in-the-middle attacks, repository compromises, and freeze attacks.

• Signed Manifests: The update client must never simply download and execute a binary. It must first poll a version endpoint to retrieve a strictly structured, JSON-based release manifest. This manifest details the latest version, release channels, and the exact cryptographic hashes of the target artifacts. The manifest itself must be digitally signed, preventing an adversary from altering the expected hashes in transit.
• Artifact Hashing: Upon downloading an update payload to a secure temporary directory, the updater must independently calculate the SHA-256 hash of the binary and assert equality against the hash declared in the verified manifest45. Execution is strictly prohibited if the hashes diverge.
• Downgrade Prevention (Anti-Rollback): The updater must maintain an internal watermark of the currently installed version and structurally reject any manifest instructing it to install an older iteration22. This prevents attackers from executing a rollback attack, wherein they serve a legitimately signed but heavily deprecated version of the software containing known, exploitable vulnerabilities to regain a foothold on the system22.
• Partial Failure and Offline Behavior: The update routine must utilize a secondary watchdog process. If the primary service is terminated for an update but the new binary fails to initialize successfully within a specified timeout threshold, the watchdog must revert the executable to the previous known-good state and restart the service44. Updates must cache payloads securely, allowing installation to proceed seamlessly even if external network connectivity is lost mid-transaction.
• Channel Selection: The architecture must support distinct distribution rings (e.g., canary, beta, stable). This allows the development team to push updates to a fractional percentage of the active fleet, monitoring crash telemetry and system impact before promoting the release manifest to the global population.

8. SBOM and Provenance Design

Transparency in the software supply chain requires the publication of machine-readable artifacts alongside every executable release, allowing enterprise consumers and security researchers to audit the composition and origin of the software23.

CycloneDX for Security-Centric SBOMs

The pipeline must generate a comprehensive Software Bill of Materials (SBOM) for every release. The industry supports two primary formats: SPDX 3.0 and CycloneDX 1.6+47. While SPDX 3.0 has matured significantly, introducing dedicated Build and Security profiles49, CycloneDX remains the superior choice for this specific security-first operational context. CycloneDX was designed inherently for application security, offering native, mature integration with Vulnerability Exploitability eXchange (VEX) data and cryptographic asset inventories47. By standardizing on CycloneDX, the evidence page can explicitly map components to known CVEs and provide machine-readable justifications for why specific vulnerabilities are not exploitable in the current deployment configuration48.

SLSA v1.0 Provenance

In addition to the SBOM, the release pipeline must generate a Supply-chain Levels for Software Artifacts (SLSA) v1.0 provenance attestation20. This JSON document cryptographically binds the final compiled artifact to the specific source code repository and the ephemeral build environment that produced it. The provenance document must specify the predicateType as https://slsa.dev/provenance/v1 and detail the exact buildDefinition and resolvedDependencies54. Crucially, to achieve SLSA Level 3 compliance, the provenance must be non-falsifiable21. This is achieved by ensuring the builder.id reflects a hardened, isolated CI/CD runner (e.g., GitHub Actions hosted runners) where the build script itself cannot alter the generated provenance telemetry21. By publishing the SLSA provenance, the organization mathematically proves that the exact source code reviewed by humans is the code executing on the endpoint, with no unauthorized tampering occurring during compilation.

9. Recommended CI/CD Stages and Separation of Duties

To align with the NIST SP 800-218 Secure Software Development Framework (SSDF) and the CISA Secure by Design pledge, the CI/CD pipeline must enforce strict separation of duties and environment isolation23. The pipeline is segmented into non-overlapping stages of execution.

1. Source Stage: Modifications to the codebase must occur via pull requests on a protected branch. Branch policies enforce that no code can be merged without at least two independent peer reviews and the successful execution of automated Static Application Security Testing (SAST) and linting checks58.
2. Dependency Stage: All third-party dependencies are strictly pinned using lockfiles. A Software Composition Analysis (SCA) tool scans the lockfile, blocking the pipeline if any unmitigated critical or high-severity vulnerabilities are detected56.
3. Build Stage: The compilation occurs on an ephemeral, single-use virtual machine21. This environment is hermetically sealed; network access is aggressively brokered and restricted solely to approved package repositories to prevent malicious build scripts from exfiltrating data or fetching unauthorized secondary payloads21.
4. Signing Stage: Once the MSI artifact is finalized, its cryptographic hash is generated. The signing operation requests an Azure Trusted Signing signature. The credentials (e.g., Service Principal secrets) required to request this signature are highly restricted, injected as protected variables only during this specific pipeline stage, and are completely inaccessible to developers with standard repository access34.
5. Evidence Stage: The pipeline concludes by generating the CycloneDX SBOM, the SLSA provenance JSON, and the public release manifest, pushing these artifacts to the public evidence repository21.

10. Complete Artifact Manifest Schema

The artifact manifest acts as the central source of truth for the update engine and public download verifications. It must adhere to a strict JSON schema:

JSON { "$schema": "https://remoteendpoints.com/schemas/v1/release-manifest.json", "product": "LocalEndpoint Connect", "version": "1.4.2", "releaseChannel": "stable", "releaseDate": "2026-07-14T18:00:00Z", "minimumSupportedWindows": "10.0.19045", "artifacts": \[ { "architecture": "x64", "packageType": "MSI", "downloadUrl": "https://dl.remoteendpoints.com/1.4.2/LocalEndpointConnect\_x64.msi", "sizeBytes": 42591823, "hashes": { "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" }, "signature": { "publisher": "RemoteEndpoints Inc", "certificateAuthority": "Microsoft ID Verified CS EOC CA 04", "timestamped": true } } \], "evidence": { "sbomUrl": "https://dl.remoteendpoints.com/1.4.2/sbom-cyclonedx.json", "provenanceUrl": "https://dl.remoteendpoints.com/1.4.2/slsa-provenance.json", "containmentReportUrl": "https://dl.remoteendpoints.com/1.4.2/containment.json" } }

11. Release-Gate Matrix

Every build must pass a series of automated and manual validation gates before achieving general availability.

12. Owned-Fixture End-to-End Test Plan for Unattended Operation

Validating unattended capabilities requires an environment devoid of human interaction, rigorously monitoring operational boundaries and containment. The testing protocol utilizes Windows Sandbox, an ephemeral, lightweight hypervisor environment native to Windows 11, configured via programmatic .wsb files to simulate clean, isolated host scenarios61.

1. Install: A PowerShell script triggers a silent MSI installation (/qn) within the sandbox68. The test asserts that the Session 0 LocalEndpoint Connect service is successfully registered and transitions to the Running state.
2. Plugin Enablement: A test plugin, signed with an authorized test certificate, is deployed to the plugin directory. The test asserts that the service successfully validates the signature and initializes the plugin, while rejecting maliciously modified variants19.
3. Pairing: An automated script simulates a cryptographic pairing handshake, establishing mTLS trust with a mock remote endpoint.
4. Desktop Picture: A remote command requests a desktop capture. The test validates the architectural bifurcation: the Session 0 service must successfully spawn a minimally privileged worker process in Session 1, capture the desktop via DXGI, and transmit the payload, navigating the isolation boundary seamlessly1.
5. Prompt: An AI prompt requiring local filesystem context is submitted; the test verifies accurate response generation.
6. Status/Result (Containment Test): The telemetry payload is intercepted and validated to ensure it reports success without leaking unintended environment variables, access tokens, or out-of-scope filesystem data60.
7. Pause/Resume: The service is issued a suspend command; the test verifies the per-user worker process terminates immediately. Upon resume, the worker must gracefully respawn.
8. Credential Rotation: API pairing keys are forcefully rotated. The active session must transparently re-authenticate without dropping connection.
9. Revoke: A remote revocation command is issued. The application must immediately sever all network connections, purge local cached configurations, and halt execution.
10. Restart: The Windows Sandbox is programmatically restarted (simulating an OS reboot)72. The test verifies the Session 0 service auto-starts and re-establishes remote connectivity prior to any user logging in.
11. Network Loss: Network access is severed via the sandbox host mapping (\<Networking\>Disable\</Networking\>)61. The application must enter a graceful exponential backoff retry loop without crashing or exhausting CPU resources.
12. Forced Termination: The per-user worker process is forcibly killed. The Session 0 service watchdog must detect the failure and successfully restart the worker44.
13. Uninstall: Silent uninstallation is executed. The test asserts that all binaries, logs, and SCM registrations are completely eradicated from the sandbox.

13. A Public Download Page Specification

The public download page must function as a cryptographic receipt, replacing ambiguous marketing copy with verifiable markers of trust and compliance. Required Fields:

• Exact Version Identifier: Clearly stated (e.g., v1.4.2-stable).
• Supported Windows Versions: Explicit compatibility mapping (e.g., Windows 10 19045+, Windows 11 22H2+).
• Architecture: Dedicated packages for x64 and ARM64.
• Package Size: Exact byte count.
• Cryptographic Checksum: The SHA-256 hash displayed prominently with a one-click copy button, ensuring users can verify integrity before execution.
• Signing Identity: The exact expected publisher string as it appears on the UAC prompt (e.g., "RemoteEndpoints Inc" signed via "Azure Trusted Signing").
• Certificate Verification Instructions: A persistent UI element providing step-by-step guidance on right-clicking the MSI, navigating to Properties \-\> Digital Signatures, and validating the certificate chain and RFC 3161 timestamp19.
• Security Model & Privacy Boundaries: A highly visible declaration that unattended mode requires desktop imagery capture. This section must directly address BIPA compliance, mandating explicit, verifiable electronic consent prior to enablement, and detailing the data retention and destruction policies regarding biometric derivatives8.
• Safe Installation & Uninstall Steps: Explicit commands for silent deployment and complete removal.
• Support/Contact Identity: Verifiable organizational contact parameters.
• Vulnerability Disclosure: Direct links to the organization's Vulnerability Disclosure Policy (VDP) and bug bounty programs, aligning with CISA Secure by Design transparency pledges59.
• Status and Incident History: Real-time links to service uptime and historical compromise remediations.

14. A Public Release-Evidence Page Specification

Each product release is accompanied by an immutable ledger of quality and security assurance, hosted on a dedicated evidence page. Required Elements:

• Release Notes & Known Limitations: Transparent documentation of functional changes and known edge-case failures.
• SBOM Download: Direct URI to the CycloneDX 1.6+ JSON file detailing all transitive dependencies and their vulnerability posture48.
• SLSA Provenance Download: Direct URI to the SLSA v1.0 JSON attestation, mathematically proving the build origins and runner isolation20.
• Test Receipts: A summarized tabular view of the Windows Sandbox clean-machine E2E test execution, linking to raw CI logs.
• Visual Regression Status: Confirmation that UI/UX perceptual differences were evaluated, with structural shifts manually reviewed by QA.
• Dependency Audit: A summary of the SCA scan, certifying that zero unmitigated high or critical CVEs exist in the compiled artifact.

15. Exact Distinctions Among Maturity Levels

To prevent the conflation of engineering milestones with public readiness, the organization must enforce strict definitions of artifact maturity. Claims of availability must map exactly to these levels.

1. Implemented in Source: Code logic is merged into the primary branch, and unit tests execute successfully. This does not imply the code is deployable or functional in a system context.
2. Packaged: The source is compiled and bundled into the MSI database structure. This does not imply trustworthiness or integrity.
3. Signed: The MSI is cryptographically hashed, signed via Azure Trusted Signing, and timestamped. This guarantees origin and integrity, but does not imply behavioral safety or lack of vulnerabilities19.
4. Uploaded: The signed artifact is staged on the edge content delivery network (CDN).
5. Hash-Verified in Production: The deployment pipeline performs a readback of the artifact from the CDN, verifying the SHA-256 hash matches the exact output of the build runner to rule out transport corruption or CDN compromise.
6. Browser-Verified: Automated tools confirm that the web interfaces providing the download links conform strictly to WCAG 2.2 AA accessibility guidelines (e.g., minimum target sizes of 24x24 pixels, Focus Not Obscured)63.
7. Installed on a Clean Machine: The artifact has been successfully deployed, executed, and uninstalled on an isolated, ephemeral Windows Sandbox without leaving resident artifacts67.
8. Proven Through a Production End-to-End Fixture: The software successfully passes all dynamic containment tests, simulating unattended operation, credential rotation, and network loss over live internet protocols60.
9. Generally Available (GA): The release manifest is formally updated, the artifact is promoted to the stable channel, and it is broadcast to all active endpoints.

16. Wording Examples for Each Maturity Level

To maintain defensible transparency, marketing and release communications must adhere to precise phrasing corresponding to the maturity levels.

• Implemented: "The worker process logic for desktop capture has been merged into the main repository and passed unit tests."
• Packaged: "Build pipeline \#458 produced an MSI artifact of the worker process."
• Signed: "The MSI was cryptographically signed by RemoteEndpoints Inc. using an Azure Trusted Signing OV profile."
• Installed on a Clean Machine: "Release candidate v1.4.2 was successfully installed, executed, and cleanly removed in an isolated Windows Sandbox environment."
• Proven Through E2E: "The release candidate passed full unattended lifecycle validation, recovering successfully from simulated network isolation and forced termination."
• Generally Available: "Version 1.4.2 is live. The cryptographic hash, CycloneDX SBOM, and SLSA provenance attestations are available on the public evidence page."

17. Claims That Must Be Prohibited Until Evidence Exists

Vague, unsubstantiated security claims erode trust and invite regulatory scrutiny. The following marketing phrases are strictly prohibited:

• "100% Secure" or "Malware-Free": Absolutely prohibited. Use verifiable language: "Scanned for known vulnerabilities via SCA and signed to ensure integrity."
• "Approved by Microsoft" or "Trusted by SmartScreen": Prohibited. SmartScreen operates on dynamic telemetry, and Azure Trusted Signing does not constitute a behavioral endorsement by Microsoft40. Use: "Digitally signed using Microsoft Azure Trusted Signing."
• "Reproducible Builds": Prohibited unless the organization can mathematically demonstrate bit-for-bit identical compiled outputs across wholly independent build environments20. Use: "Verifiable Builds with SLSA Provenance."
• "Privacy Guaranteed": Prohibited, particularly given the severe implications of unattended desktop capture under BIPA. Use: "Compliant with explicit consent protocols governing biometric and desktop data collection and retention"8.

18. Screenshot-Driven Round Protocol

The product team's strategy of utilizing iterative, screenshot-driven UI/UX improvements—scaling to approximately 50 continuous rounds—requires a deterministic, evidence-based protocol to prevent regressions, ensure accessibility, and guarantee that frontend changes do not violate backend security boundaries. For every UI/UX round, the following elements must be documented and appended to the release evidence ledger:

• Stated Hypothesis: A definitive statement of the intended UX improvement (e.g., "Increasing the padding on the consent dialogue to satisfy WCAG Target Size requirements").
• Source Screenshots: Baseline design mockups derived from Figma or equivalent tooling.
• Automated Checks: Syntax verification, linting, and unit test results.
• Accessibility Checks: Formal validation against WCAG 2.2 AA. Specifically, ensuring that Focus Not Obscured (2.4.11) is met so keyboard users are never lost behind sticky headers, and that interactive elements meet the Target Size (Minimum) (2.5.8) of at least 24x24 CSS pixels63.
• Inspected Package: Unpacking the resulting MSI to verify that no anomalous, duplicated, or unauthorized assets (e.g., uncompressed design files, development secrets) were inadvertently included in the payload33.
• Deployment Receipt: A CI/CD log explicitly confirming successful deployment to the staging environment.
• Runtime Hash Verification: Confirmation that the active staging servers are serving the exact artifact hashes produced by the build pipeline, validating transport integrity60.
• Containment Checks: Verification that the UX changes did not inadvertently alter the network egress points, local file access permissions, or privilege boundaries of the application60.
• Live HTTP Smoke: Verification of frontend rendering and API health endpoints.
• Production Screenshots: Automated capture of the live staging environment utilizing headless browsers.
• Source/Live Comparison: Side-by-side review of design mockups versus actual production rendering.
• Documented Nondeterminism: Explicit accounting for dynamic elements in the UI (e.g., live timestamps, randomly generated user avatars, network latency indicators) that cause unavoidable screenshot variance.
• Rollback Criteria: Explicit thresholds (e.g., a 5% increase in frontend crash rates, or failure of the mTLS handshake) that will trigger an automatic revert to the previous release manifest.

19. Screenshot-Difference Policy

Evaluating visual regression automatically across 50 iterations requires a rigid, defined policy to prevent false positives and avoid subjective approvals.

• Byte Equality: Direct file comparison of image assets. This is rarely applicable to rendered UI elements due to compression artifacts and browser rendering engines.
• Pixel Equality: Compares rendered screenshots pixel-by-pixel. This approach is highly brittle due to variations in GPU rendering, OS-level text anti-aliasing, and sub-pixel shifts.
• Perceptual Comparison (Recommended): Utilizes algorithms such as the Structural Similarity Index (SSIM) to evaluate visual changes based on human perception. This allows for minor rendering variance while reliably catching severe layout shifts, missing assets, or incorrect color palettes.
• Antialiasing, Font, and Time Nondeterminism: The perceptual comparison tool must be configured to ignore sub-pixel anti-aliasing variations. Furthermore, dynamic regions (such as clocks, variable test data, or animated loading states) must be explicitly masked with bounding boxes to prevent them from triggering false failures.
• Acceptable Thresholds: Perceptual differences below a defined threshold (e.g., 1.5%) in unmasked areas are automatically approved by the pipeline.
• Mandatory Human Review: Any perceptual difference exceeding the threshold halts the pipeline and requires explicit, documented approval by an Accessibility QA lead before proceeding to deployment.
• When a Difference Blocks Release: A release is structurally blocked if visual elements overlap (violating WCAG 2.4.11 Focus Not Obscured)63, or if core interactive elements (buttons, inputs) fall below the 24x24 CSS pixel target size64.

20. Machine-Readable Evidence Schemas

To facilitate automated auditing and trust verification, the release pipeline outputs all evidence as structured JSON. Package & Deployment Receipt Schema Fragment:

JSON { "evidenceType": "DeploymentReceipt", "schemaVersion": "1.0", "buildId": "github-actions-8842", "timestamp": "2026-07-14T18:05:00Z", "deployedHashes": { "LocalEndpointConnect\_x64.msi": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" }, "containmentReport": { "networkEgressValid": true, "sessionIsolationVerified": true, "unauthorizedFileAccess": false }, "accessibilityReport": { "wcag22AA\_passed": true, "targetSizeViolations": 0, "focusObscuredViolations": 0 }, "screenshotVerification": { "perceptualDiffPercentage": 0.82, "humanReviewRequired": false, "status": "APPROVED" } }

21. Recommended Sequence of Ten Trust-Focused Public-Site Rounds

To establish immense public credibility over a continuous deployment lifecycle, the first ten iterations of the website will progressively expose the underlying trust architecture, rather than focusing solely on feature marketing.

1. Baseline Transparency: Launch the fundamental Download page featuring explicit SHA-256 hashes, exact versioning, and standard release notes.
2. Signature Verification Education: Integrate interactive guides explaining how to manually verify Azure Trusted Signing certificates and RFC 3161 timestamping mathematically within the Windows OS19.
3. SBOM Availability: Embed links to the CycloneDX v1.6 SBOM JSON downloads for every release, emphasizing deep component transparency and VEX data48.
4. Provenance Publication: Expose the SLSA v1.0 provenance attestations, detailing the isolated build pipeline and providing instructions on how to verify the builder.id20.
5. BIPA Consent UX: Introduce a mandatory, highly visible digital consent gate detailing unattended desktop capture privacy boundaries, biometric retention schedules, and destruction policies prior to initiating the download8.
6. Accessibility Compliance: Attest to WCAG 2.2 AA standards, demonstrating accessible authentication, consistent help mechanisms, and focus visibility across the entire web property63.
7. Containment Dashboard: Publish aggregated, anonymized metrics proving that application instances respect network and file-system containment boundaries in production60.
8. Automated Test Receipts: Embed live feeds or historical logs of the Windows Sandbox clean-machine E2E test results, proving flawless installation and removal61.
9. Vulnerability Disclosure: Publish a formal CISA-aligned Vulnerability Disclosure Policy (VDP), guaranteeing safe harbor for security researchers and committing to rapid CVE remediation59.
10. Unified Evidence Ledger: Combine all preceding elements into a unified "Trust Center" dashboard, linking specific releases to their immutable Git commit hashes, SAST/SCA audit results, and deployment receipts, creating an unbroken chain of cryptographic custody.

22. Incident-Response Plan (Compromise Scenario)

The architecture must assume a state of eventual breach. If an installer package, a signing key, the update server, or an administrative account is suspected of compromise, the following deterministic response plan is executed:

1. Containment & Severance: Instantly sever external access to the compromised asset. If the updater server is compromised, DNS routes are blackholed. If an administrative account is breached, all sessions are immediately invalidated via the identity provider.
2. Key Revocation: If the Azure Trusted Signing identity is compromised, an administrator accesses the Azure Portal, permanently deletes the affected Certificate Profile, and revokes the underlying Managed Identity/Service Principal16. This triggers a CRL update, invalidating the signatures19.
3. Artifact Revocation: Remove all affected releases from the CDN. Crucially, update the TUF release manifest to explicitly mark the compromised versions as deprecated and malicious. This triggers the downgrade-prevention and anti-rollback mechanisms in active client software, preventing execution22.
4. Forensic Preservation: Isolate and snapshot all logs, CI/CD runner states, and infrastructure telemetry for root-cause analysis, fulfilling the CISA pledge to provide evidence of intrusions59.
5. Client Mitigation: For users running the compromised software, publish a remediation script and heavily communicate the incident via the Vulnerability Disclosure channels. The surviving software architecture must be capable of executing a forced self-termination and clean uninstallation command.
6. Re-establishment of Trust: Rebuild the infrastructure from immutable Infrastructure-as-Code (IaC) templates. Generate a new Azure Trusted Signing Profile, rotate all API pairing keys, and issue a patched release. Publish a comprehensive post-mortem detailing the attack vector, the containment timeline, and the structural remediation implemented.

23. Standards/Source Matrix

The architectural decisions within this report are derived directly from the primary standards governing software supply chain security and privacy in 2026\.

Works cited

1. Microsoft Windows Session 0 Isolation and Interactive Services Detection, https://kb.firedaemon.com/support/solutions/articles/4000086228-microsoft-windows-session-0-isolation-and-interactive-services-detection
2. Windows Session 0 Isolation & Covenant Integrity | by ThatOneSecGuy \- Medium, https://thatonesecguy.medium.com/windows-session-0-isolation-covenant-integrity-7a01ff2fb5ee
3. Screen recording of Windows "session 0" \- Super User, https://superuser.com/questions/848106/screen-recording-of-windows-session-0
4. Screen recording from a Windows service which is running under local system account, https://learn.microsoft.com/en-us/answers/questions/5875437/screen-recording-from-a-windows-service-which-is-r
5. Screenshot of process under Windows Service \- Stack Overflow, https://stackoverflow.com/questions/1445788/screenshot-of-process-under-windows-service
6. Windows service couldnt get screenshot in windows 7 \- Stack Overflow, https://stackoverflow.com/questions/7454106/windows-service-couldnt-get-screenshot-in-windows-7
7. Per-user services in Windows \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/application-management/per-user-services-in-windows
8. Illinois BIPA: Biometric Data, Device Fingerprinting, and Website Liability | Lokker, https://lokker.com/privacy-law/bipa
9. How Illinois BIPA Restricts Tracking Remote Employee | IL \- Miller Law Firm, https://www.millerlawfirm.org/illinois-employment-law/how-illinois-bipa-restricts-tracking-remote-employee
10. Jump in Facial and Voice Recognition Raises Privacy, Cybersecurity, Civil Liberty Concerns, https://www.jacksonlewis.com/insights/jump-facial-and-voice-recognition-raises-privacy-cybersecurity-civil-liberty-concerns
11. Illinois Biometric Information Privacy Act (BIPA) \- NoahFace, https://www.noahface.com/privacy/bipa
12. 1 BIOMETRIC INFORMATION PRIVACY POLICY AND CONSENT Advanced Medical Transport of Central Illinois (“The Company”) has instit, https://www.amtci.org/documents/BIPA\_Policy2021.pdf
13. Don't Run Prints: Illinois's Biometric Privacy Law Used Against Employers, https://www.employmentlawinsights.com/2021/07/dont-run-prints-illinoiss-biometric-privacy-law-used-against-employers/
14. Understanding the New Code-Signing Certificate Validity Change | DigiCert, https://www.digicert.com/blog/understanding-the-new-code-signing-certificate-validity-change
15. Code Signing Certificates Drop to 460 Days in 2026: What to Do About it \- AppViewX, https://www.appviewx.com/blogs/460-day-code-signing-certificate-2026/
16. CA/B Forum Code Signing 2026: Key Changes & Impact \- Accutive Security, https://accutivesecurity.com/code-signing-2026/
17. Latest Code Signing Baseline Requirements | CA/Browser Forum, https://cabforum.org/working-groups/code-signing/requirements/
18. Windows Code Signing with Azure Trusted Signing: End-to-End Guide \- keyq.cloud, https://www.keyq.cloud/blog/windows-code-signing-with-azure-trusted-signing/
19. Code Signing 101: Locking Down Your Software Supply Chain | Encryption Consulting, https://www.encryptionconsulting.com/locking-down-your-software-supply-chain/
20. Provenance \- SLSA.dev, https://slsa.dev/spec/v0.1/provenance
21. SLSA Levels Explained: A Practical Compliance Checklist \- Secure Pipelines, https://secure-pipelines.com/ci-cd-security/slsa-levels-explained-practical-compliance-checklist/
22. ESF:Securing the Software Supply Chain Recommended Practices for Suppliers \- CISA, https://www.cisa.gov/sites/default/files/2024-08/SECURING\_THE\_SOFTWARE\_SUPPLY\_CHAIN\_SUPPLIERS\_508.pdf
23. Secure by Design \- CISA, https://www.cisa.gov/securebydesign
24. Secure by Design | Ivanti, https://www.ivanti.com/resources/secure-by-design/2024
25. Exploiting Windows MSIX Packages for Persistent and Covert Malware Distribution, https://cyberpress.org/windows-msix/
26. MSIX vs MSI: How to convert your MSI to MSIX in 2026 \- Advanced Installer, https://www.advancedinstaller.com/msi-to-msix-conversion-update.html
27. rescap Capability \- Microsoft Q\&A, https://learn.microsoft.com/en-my/answers/questions/5652036/rescap-capability
28. App capability declarations \- UWP applications \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/uwp/packaging/app-capability-declarations
29. Windows Application Sandboxing \- Community Wiki, https://discuss.privacyguides.net/t/windows-application-sandboxing/27336
30. Top 10 Best Msi Packaging Software of 2026 \- Worldmetrics, https://worldmetrics.org/best/msi-packaging-software/
31. Best Msi Creation Software (2026) \- Gitnux, https://gitnux.org/best/msi-creation-software/
32. Robot \- Installing on Windows OS \- UiPath Documentation, https://docs.uipath.com/robot/standalone/latest/admin-guide/windows-installations
33. Extract MSI and Files from EXE Installers — Complete Packaging Guide 2026 | Nyxshima, https://www.nyxshima.com/extract-msi-and-other-files-from-executable-installers-easily/
34. How to Set Up Azure Trusted Signing to Sign an EXE? \- Security Boulevard, https://securityboulevard.com/2026/01/how-to-set-up-azure-trusted-signing-to-sign-an-exe/
35. Sign your MSIX package \- end-to-end guide \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/msix/package/sign-msix-package-guide
36. How to Use Azure Trusted Signing with XLS Padlock: A Step-by-Step Guide, https://www.xlspadlock.com/blog/azure-trusted-signing-exe-xls-padlock-guide
37. Azure.CodeSigning.Dlib.dll was not found | G.D.G. Software Forum, https://www.gdgsoft.info/t/azure-codesigning-dlib-dll-was-not-found.8094/
38. The Truth Behind Short-Lived Code Signing Certificates and Rising Costs, https://twit.tv/posts/tech/truth-behind-short-lived-code-signing-certificates-and-rising-costs
39. CA/Browser Forum Baseline Requirements — Rules Governing Public TLS Certificates, https://www.qcecuring.com/education/standards/ca-browser-forum-baseline-requirements
40. Azure Trusted Signing: still seeing SmartScreen warnings from new intermediate CAs, https://learn.microsoft.com/en-us/answers/questions/5861538/azure-trusted-signing-still-seeing-smartscreen-war
41. Azure Trusted Signing: new intermediate CAs causing SmartScreen warnings, https://learn.microsoft.com/en-us/answers/questions/5855442/azure-trusted-signing-new-intermediate-cas-causing
42. Azure Trusted Signing new intermediate CAs (AOC CA 03, EOC CA 04\) trigger SmartScreen warnings — all previous CAs worked fine \- Microsoft Learn, https://learn.microsoft.com/fr-fr/answers/questions/5853144/azure-trusted-signing-new-intermediate-cas-(aoc-ca
43. SmartScreen warnings triggered after silent migration from EOC CA 02 to AOC CA 03 (and then to EOC CA 03\) · Issue \#128 · Azure/artifact-signing-action \- GitHub, https://github.com/Azure/artifact-signing-action/issues/128
44. Unattended install vs deploy from vm template. What's your take and why? : r/sysadmin, https://www.reddit.com/r/sysadmin/comments/pnimuq/unattended\_install\_vs\_deploy\_from\_vm\_template/
45. What Is Code Signing? Definition, How It Works, and Why It Matters for Supply Chain Security (2026) \- Minimus, https://www.minimus.io/post/what-is-code-signing-why-it-matters-for-supply-chain-security-2026
46. Software supply chain: What it is and how to keep it secure \- CircleCI, https://circleci.com/blog/secure-software-supply-chain/
47. SBOM Formats Compared: CycloneDX vs SPDX \- Sbomify, https://sbomify.com/2026/01/15/sbom-formats-cyclonedx-vs-spdx/
48. CycloneDX vs SPDX: Picking Your CRA-Compliant SBOM Format, https://craevidence.com/cra-compliance/sbom/cyclonedx-vs-spdx
49. Description \- SPDX Specification 3.0.1, https://spdx.github.io/spdx-spec/v3.0.1/model/Build/Build/
50. The Complete Guide to SPDX | FOSSA Learning Center, https://fossa.com/learn/spdx/
51. SPDX 3.0 Revolutionizes Software Management in Systems with Enhanced Functionality and Streamlined Use Cases \- Linux Foundation, https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
52. CycloneDX vs SPDX: SBOM Format Comparison 2026 \- Safeguard, https://safeguard.sh/resources/blog/cyclonedx-vs-spdx-sbom-format-comparison-2026
53. Provenance \- SLSA.dev, https://slsa.dev/spec/v1.0/provenance
54. Provenance \- SLSA.dev, https://slsa.dev/spec/v1.0-rc1/provenance
55. SLSA provenance specification \- GitLab Docs, https://docs.gitlab.com/ci/pipeline\_security/slsa/level\_3/provenance\_v1/
56. Stay Compliant with NIST SP 800-218 and CISA Attestation Requirements \- Sonatype, https://www.sonatype.com/resources/guides/stay-compliant-nist-sp-800-218-cisa-requirements
57. What is the Secure Software Development Framework (SSDF)? \- JFrog, https://jfrog.com/learn/grc/ssdf/
58. What Is NIST SSDF? Why It Matters & Best Practices, https://apiiro.com/glossary/nist-ssdf/
59. Cybersecurity & Infrastructure Security Agency (CISA) Pledge \- Strata.io, https://www.strata.io/blog/product-engineering/cisa-pledge/
60. Governing AI-Assisted Security Operations: A Design Science Framework for Operational Decision Support \- arXiv, https://arxiv.org/html/2605.09534v1
61. Use and configure Windows Sandbox | Microsoft Learn, https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-configure-using-wsb-file
62. Provisioning Windows Sandbox \#windows \- GitHub Gist, https://gist.github.com/qnimbus/83a86ee072d2b4dbfd13f2fe901796df
63. The New Requirements for WCAG 2.2 \- Vision Australia, https://visionaustralia.org/business-consulting/digital-access/blog/the-new-requirements-for-wcag-2-2
64. What's New in WCAG 2.2 | Web Accessibility Initiative (WAI) \- W3C, https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
65. WCAG 2.2 Updates | Accessibility Resources and Code Examples \- Deque University, https://dequeuniversity.com/resources/wcag-2.2/
66. Install Windows Sandbox | Microsoft Learn, https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-install
67. Windows Sandbox for Safe Testing | McGarrah Technical Blog, https://mcgarrah.org/windows-sandbox/
68. GitHub \- memstechtips/UnattendedWinstall: Personalized Unattended Answer Files that helps automatically debloat and customize Windows 10 & 11 during the installation process., https://github.com/memstechtips/UnattendedWinstall
69. Windows Sandbox for automated application (package) testing \- Advanced Installer, https://www.advancedinstaller.com/forums/viewtopic.php?t=52896
70. Taking Screen Captures of Remote Desktops on Horizon Windows Client \- Omnissa Docs, https://docs.omnissa.com/bundle/HorizonClient-WindowsGuideV2406/page/TakingScreenCapturesofRemoteDesktopsonHorizonWindowsClient.html
71. Spatial Relationships: Containment, Intersection, and Adjacency, https://spatial-eye.com/blog/spatial-analysis/spatial-relationships-containment-intersection-and-adjacency/
72. Exploring Windows Sandbox: Application Install and PowerShell Script Testing, https://sandboxitsolutions.com/exploring-windows-sandbox-application-install-and-powershell-script-testing/
73. Rapid7 CISA Secure by Design Pledge, https://www.rapid7.com/cdn/assets/blt119ef630f26beea6/69d4c0243b53e14f1e53a8f0/Rapid7\_CISA\_Secure\_by\_Design\_Pledge.pdf
74. What's New in WCAG 2.2: The 9 New Success Criteria Explained \- AudioEye, https://www.audioeye.com/post/whats-new-with-wcag-2-2/
75. What's new in WCAG 2.2 \- TetraLogical, https://tetralogical.com/blog/2023/10/05/whats-new-wcag-2.2/
76. CobbleStone® Takes CISA's Secure by Design Pledge for as Security Attestation, https://www.cobblestonesoftware.com/blog/cobblestone-takes-cisas-secure-by-design-pledge
77. Choosing the Right SBOM Standard: SPDX vs. CycloneDX \- Sonatype, https://www.sonatype.com/blog/comparing-sbom-standards-spdx-vs.-cyclonedx-vs.-swid
78. Will there be federal facial recognition regulation in the US? \- IAPP, https://iapp.org/news/a/u-s-facial-recognition-roundup
79. Class 6: Workplace Privacy, https://www.fishlawfirm.com/employment-law-class/class-6/