European Union

Security

Security by design

Unauthorised Access

Confidentiality of data

Attack surfaces

Security patches

Security by design

DMA vs CRA

Conflicts

  • DMA forbids default security measures

  • CRA requires default security measures

  • Article 6.4 of the DMA forbids default configurations by gatekeepers including those that protect the security and integrity of users.

  • Chapter 2 of the CRA mandates that manufacturers factor in cyber security in the design, development, and production of products with digital elements.

     

    The requirements of the DMA, which ban default security configurations, force device producers to allow millions of apps that have not been vetted, grant interoperability to untrustworthy software, and divorce apps on devices from safety, security, and privacy requirements, run counter to what will be required by the CRA.

     

    For more information read our analysis here.

Unauthorised Access

DMA vs CRA

Conflicts

  • DMA prevents device producers from creating operating systems that ensure security and privacy

  • CRA requires operating systems to ensure no unauthorized access

  • Articles 3 and 4 of the DMA removes device producers from ensuring safety, security, and privacy of apps while Annex I of the CRA requires that products with digital elements shall ensure protection from unauthorized access.

     

    For more information read our analysis here.

Confidentiality of data

DMA vs CRA

Conflicts

  • DMA prevents device producers from requiring apps to have data protection policies

  • CRA requires companies to protect the confidentiality of data

  • Chapter 7 of the CRA requires that all parties respect the confidentiality of information and data while Paragraph 38 of the DMA requires gatekeepers to allow users to be able to circumvent official app stores, which is how existing privacy protections are enforced.

     

    Given the state of cybersecurity today, and the activity of cyber criminals, nation-state actors, and privacy abusers, there is significant concern that forcing mobile device producers to ‘open-up’ their devices to any and every app will predictably lead to significant cyber risk and loss for consumers, enterprises, critical infrastructure, and government networks and data, all of which use the devices that will now be subject to the DMA app store provisions.

     

    For more information read our analysis here.

Attack surfaces

DMA vs CRA

Conflicts

  • DMA requires device producers to allow unvetted apps, expanding the attack surface of devices

  • CRA requires systems to be designed to limit attack surfaces

  • Annex I, Section 1(3)(h) of the CRA requires that “products with digital elements shall… be designed, developed and produced to limit attack surfaces, including external interfaces”. However, the DMA requires that users be allowed to download unvetted apps through third-parties, which can expand the attack surface and unvetted external interfaces.

     

    Today, the official app stores of the ‘gatekeepers’ undertake security and privacy reviews and keep out these security and privacy risks. They also remove apps that violate the law, or the device terms of service, or fail to follow the security or privacy promises the app made to gain access to the official app store. They require patching, and secure delivery of patches. All these activities are vital to creating a safe and secure environment for the user.

     

    For more information read our analysis here.

Security patches

DMA vs CRA

Conflicts

  • DMA does not allow device producers to ensure security patches are applied

  • CRA requires operating systems to ensure security patches are implemented immediately

  • Annex I, Section 2(8) of the CRA requires that “Manufacturers of the products with digital elements shall… ensure that, where security patches or updates are available to address identified security issues, they are disseminated without delay and free of charge…” However, if apps are not from the official app store, the device producer cannot ensure essential patches are ever delivered and applied.

     

    Currently, device producers create combinations of hardware and software protections that are integrated and designed to ‘build security in’ from the start, using systems engineering within the device, requirements in app stores that apps pass machine and human security checks before being available to be downloaded onto the device, require that app developers state their privacy policies and adhere to them, and require and manage patching of vulnerabilities in apps by a secure methodology.

     

    For more information read our analysis here.