Mobile application CRA implementation should account for the controls owned by the app manufacturer and the controls supplied by iOS or Android. The app should minimise permissions, validate deep links and inter-app input, protect credentials and tokens, secure backend APIs, manage third-party SDK risk, authenticate updates through the distribution model and define what happens when older app versions remain installed. App-store review and mobile OS sandboxing can support security, but they do not replace the manufacturer's CRA risk assessment, vulnerability handling or technical documentation.
Mobile Applications Are Not Automatically Annex III Products
Annex III does not contain a general category for all mobile applications. Classification follows core functionality. A mobile password manager, VPN product, standalone browser or anti-malware product can meet a Class I technical description, while a product whose core functionality is a firewall or intrusion detection or prevention system can meet a Class II description. An ordinary messaging, productivity, retail or service application should not be classified as important solely because it runs on a smartphone.
Separate Mobile OS Controls From Application Controls
Mobile platforms provide code signing, sandboxing, permission systems, secure storage APIs and application distribution controls, but the app manufacturer remains responsible for the security of the product it supplies. The technical file should identify which controls are inherited from the supported mobile operating system, which are configured by the application and which security properties depend on backend services controlled by the manufacturer.
Request Only the Permissions the Product Needs
Camera, microphone, location, contacts, Bluetooth, local network, photos and notification permissions can expose sensitive data or capabilities. The manufacturer should map each requested permission to a product function, avoid unnecessary access, handle denial safely and reassess permissions when features change. Permission prompts should not be used as a substitute for application-level authorization when several users or roles can operate the same account.
Deep Links and App-to-App Interfaces Are External Input
Custom URL schemes, universal links, app links, intents, share extensions and inter-app messages can allow another application or website to invoke mobile functionality. The app should validate parameters, authentication state and authorization before performing sensitive actions. Security testing should include crafted links, duplicated handlers, unexpected navigation state and attempts to bypass normal user confirmation.
Protect Tokens and Secrets With Platform Security Primitives
Mobile apps commonly store refresh tokens, session identifiers, encryption keys and device-bound credentials. The design should use appropriate platform-protected storage and avoid embedding reusable secrets in application packages where they can be extracted. Logs, analytics events, crash reports, clipboard use and backups should be reviewed for accidental copies of sensitive values.
Backend APIs Need Object-Level and Action-Level Authorization
A mobile interface can hide buttons or screens, but that does not enforce authorization on the server. Backend APIs should independently verify which user, device or tenant can read or change each protected resource and action. The risk assessment should cover token theft, replay, account switching, device enrollment, session revocation and abuse of undocumented or older API versions.
Third-Party SDKs Can Observe Sensitive App Activity
Analytics, advertising, payment, crash-reporting, social and customer-support SDKs execute inside the application process and may receive application data or permissions. Manufacturers should inventory SDK versions, understand the data and capabilities exposed to them, monitor vulnerabilities and remove abandoned dependencies. A software bill of materials or equivalent component record should identify which SDK version is included in each released app build.
Push Notifications Are a Command and Data Channel
Push services are often used for alerts, authentication prompts, deep links or workflow triggers. Applications should treat push payloads as untrusted input, avoid placing sensitive information in notification content without considering device-lock exposure, and verify authorization before a notification-triggered action changes protected state. The architecture should distinguish the platform push provider from manufacturer-controlled notification services.
App-Store Distribution Does Not Replace Manufacturer Responsibility
Distribution through an app store can provide package signing, review and update delivery controls, but the CRA obligations remain tied to the manufacturer and the product. The manufacturer should preserve release records, identify the binary and version placed on the market, maintain vulnerability-handling processes and ensure required product information and conformity evidence are available through appropriate channels.
Mobile Updates Must Account for Users Who Stay on Old Versions
App-store updates are not always installed immediately, and some users may remain on older mobile operating systems that cannot receive the newest app build. The support model should define supported app and OS versions, how urgent security updates are communicated, when backend access from vulnerable versions is restricted and how the manufacturer distinguishes an unsupported version from a temporarily unpatched installation.
A Required Backend Can Be Part of the CRA Product Boundary
Many mobile apps depend on manufacturer-controlled authentication, synchronization, content processing or device-control services. Where remote processing meets the CRA definition and its absence would prevent the application from performing one of its functions, it can be part of the product with digital elements. The technical documentation should map the app build to relevant backend APIs, authentication paths and remotely delivered functionality.
Mobile Evidence Should Be Build-Specific
A useful mobile technical file should identify the app version and build, supported iOS or Android versions, entitlements and permissions, embedded SDKs, backend API versions, authentication design, deep-link handlers, security test results and update history. If iOS and Android implementations use different frameworks, permissions or storage mechanisms, the evidence should record those differences rather than treating both packages as one identical security implementation.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.