Desktop software CRA work should follow the application's real attack surface: installer and updater privilege, file and document parsing, plugins and extensions, IPC, local credential and configuration storage, operating-system integrations, third-party libraries and any remote services needed for product functions. The manufacturer should define which parts are shipped locally, which are remotely controlled, how security updates reach installed users and whether the product's core functionality places it in an Annex III category before selecting the conformity route.
Desktop Software Is Not Automatically an Important Product
Annex III does not contain a general category for all desktop applications. A desktop product becomes an important Class I or Class II product when its core functionality meets a listed category, such as a standalone browser, password manager, VPN product, anti-malware product, firewall or intrusion detection or prevention system. Ordinary desktop software should therefore be classified by what it fundamentally does rather than by the operating system on which it runs.
Treat the Installer as a Separate Privileged Attack Surface
Desktop installers often run with higher privileges than the application itself and can write executables, services, drivers, registry entries or system configuration. The threat model should cover package authenticity, elevation flow, temporary files, installation paths, DLL or library loading, rollback behavior and whether a lower-privilege user can influence privileged installation operations.
Auto-Updaters Can Become Fleet-Wide Control Channels
An automatic updater can replace executable code across the installed user base, so compromise of its signing keys, manifests, transport or update service can have broad impact. Manufacturers should authenticate updates, protect integrity, control signing material, validate update metadata and test interrupted installation and rollback. Update evidence should identify which application versions remain supported and how urgent security fixes reach users who disable automatic updates.
File and Document Parsers Need Hostile-Input Testing
Desktop applications frequently open documents, images, archives, project files, media or other attacker-controlled content. Those parsers can expose memory, deserialisation, path-handling and logic vulnerabilities before a user has explicitly trusted the content. Product-specific security testing should focus on the actual file formats and import paths the software supports, including preview and background indexing features that process files automatically.
Plugin Systems Expand the Product Trust Boundary
Plugins, extensions, scripts and add-ons can execute with access to application data or host capabilities. The manufacturer should document who can publish extensions, how they are installed, what permissions they receive, whether signatures or repository controls are used and how a malicious or abandoned plugin can be disabled. The technical file should separate security guarantees of the base product from assumptions placed on third-party extensions.
Local Storage Can Contain High-Value Secrets
Desktop software may store authentication tokens, API keys, encryption keys, cached documents, configuration and personal data on the local system. The risk assessment should identify which data needs confidentiality or integrity protection, whether operating-system credential stores or other protected storage are used, and how backups, logs and crash reports may create secondary copies of sensitive information.
IPC and Local Services Need Authorization Checks
Applications can communicate through sockets, named pipes, local HTTP services, shared memory, custom URL handlers or privileged helper processes. Local reachability should not be treated as automatic authorization. Manufacturers should document which processes can invoke sensitive operations, validate caller identity or capability where appropriate and test whether a lower-privilege process can abuse a privileged helper.
Operating-System Integrations Change the Risk Profile
Shell extensions, file associations, browser integrations, background services, kernel drivers and accessibility or automation APIs can give desktop software deeper access to the host. Each integration should be included in the architecture and risk assessment. Optional integrations should not silently receive the same trust as the main application, and privileged components should be separately versioned and updateable where practical.
Remote Services Can Be Part of the Desktop Product Boundary
A desktop client may depend on manufacturer-controlled authentication, synchronization, licensing, collaboration or processing services. Where remote processing meets the CRA definition and its absence would prevent the product from performing one of its functions, it can form part of the product with digital elements. The manufacturer should document client-to-service authentication, API authorization, command or data integrity and degraded behavior when the remote service is unavailable.
Third-Party Libraries Need Release-Specific Traceability
Desktop applications commonly bundle frameworks, media codecs, cryptographic libraries, database engines and language runtimes. The manufacturer should maintain component inventory and be able to identify which shipped release contains a vulnerable dependency. Remediation planning should account for statically linked or bundled components that will not be patched automatically by the user's operating system.
Uninstallation and Data Removal Are Part of Product Security
A desktop product may leave services, credentials, update agents or sensitive data behind after removal. The CRA does not prescribe one uninstallation design, but the risk assessment should consider whether residual privileged components or secrets create an avoidable attack surface. Where the product offers account removal, reset or secure deletion features, their behavior should be documented and tested.
Evidence Should Reconstruct the Exact Desktop Release
A desktop-software technical file should tie the application version to installer and updater versions, bundled dependencies, privileged helpers, supported operating systems, remote-service dependencies, security configuration and test evidence. This is particularly important when the same marketing version is packaged differently for Windows, macOS and Linux because the security architecture and attack surface can differ between platforms.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.