Catalog / Ships a mobile app / LXD-6485

Ships a mobile app, in the European Union

Each law's tag says when it binds: since in force from , in 4 weeks not yet in force

Product Liability Directive 85/374/EEC, producer liability for defective productssince 6 lines

Council Directive 85/374/EEC · Read the law's page

  • Check whether your software is a 'product' under Article 2 as replaced by Directive 1999/34/EC, which covers all movables, even if incorporated into another movable or into an immovable, and electricity; the definition does not name software.
  • Be able to show when you first put each product into circulation: you are not liable if you prove you did not put it into circulation, or that the defect probably did not exist then or came into being afterwards (Art. 7(a) and (b)).
  • If you import a product into the Community for sale, hire, leasing or any form of distribution in the course of your business, you answer as its producer (Art. 3(2)); if you supply a product whose producer cannot be identified, you are treated as the producer unless you tell the injured person within a reasonable time who the producer or your own supplier is (Art. 3(3)).
  • If you make a component, you are not liable where the defect is attributable to the design of the product the component was fitted in or to the instructions given by that product's manufacturer (Art. 7(f)).
  • Do not count on a contract term to limit or exclude your liability to an injured person (Art. 12).
  • Keep in mind that the injured person's rights against you are extinguished 10 years after you put the actual product that caused the damage into circulation, unless proceedings have been instituted against you in the meantime (Art. 11).
Medical Devices Regulation, Software Development, Information Security and IT Security Information Requirementssince 6 lines

Regulation (EU) 2017/745, Annex I, sections 17.2, 17.4 and 23.4(ab) · Read the law's page

  • It reaches you if you are a manufacturer that places on the EU market, or puts into service, a medical device, which includes software intended by the manufacturer to be used for human beings for a specific medical purpose, whether the software is incorporated in a device or is a device in itself (Articles 2, point (1), 5(2) and 10(1)).
  • Develop and manufacture the software in accordance with the state of the art, taking into account the principles of development life cycle, risk management, including information security, verification and validation (Annex I, section 17.2).
  • Where the software is intended to be used in combination with mobile computing platforms, design and manufacture it taking into account the specific features of the mobile platform and the external factors related to their use (section 17.3).
  • Set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorized access, necessary to run the software as intended (section 17.4).
  • Include those minimum requirements in the instructions for use of a device that incorporates electronic programmable systems, including software, or of software that is a device in itself (section 23.4, point (ab)).
  • A device with a valid certificate issued under Directive 90/385/EEC or Directive 93/42/EEC may be placed on the market or put into service until the dates fixed in Article 120(3a) and (3b) only if the conditions of Article 120(3c) are met.
Military end-use catch-all (Article 4)since 2 lines

Regulation (EU) 2021/821, Art. 4 · Read the law's page

  • Obtain an authorization before you export software not listed in Annex I if the competent authority has informed you that it is or may be intended wholly or partly for a weapons of mass destruction use or for a military end-use in a country under an arms embargo (Regulation (EU) 2021/821 Art. 4(1)).
  • Notify the competent authority if you are aware that software you propose to export, not listed in Annex I, is intended for any of those uses; the authority decides whether an authorization is required (Art. 4(2)).
Cyber-surveillance items catch-all (Article 5)since 2 lines

Regulation (EU) 2021/821, Art. 5 · Read the law's page

  • Obtain an authorization before you export cyber-surveillance items not listed in Annex I if the competent authority has informed you that they are or may be intended wholly or partly for use in connection with internal repression or serious violations of human rights and international humanitarian law (Regulation (EU) 2021/821 Art. 5(1)).
  • Notify the competent authority if your due diligence shows that cyber-surveillance items you propose to export, not listed in Annex I, are intended for such a use; the authority decides whether an authorization is required (Art. 5(2)).
In Vitro Diagnostic Medical Devices Regulation, Software Development, Information Security and IT Security Information Requirementssince 6 lines

Regulation (EU) 2017/746, Annex I, sections 16.2, 16.4 and 20.4.1(ah) · Read the law's page

  • It reaches you if you are a manufacturer that places on the EU market, or puts into service, an in vitro diagnostic medical device, which includes software intended by the manufacturer to be used in vitro for the examination of specimens derived from the human body, whether the software is incorporated in a device or is a device in itself (Articles 2, point (2), and 10(1)).
  • Develop and manufacture the software in accordance with the state of the art, taking into account the principles of development life cycle, risk management, including information security, verification and validation (Annex I, section 16.2).
  • Where the software is intended to be used in combination with mobile computing platforms, design and manufacture it taking into account the specific features of the mobile platform and the external factors related to their use (section 16.3).
  • Set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorized access, necessary to run the software as intended (section 16.4).
  • Include those minimum requirements in the instructions for use of a device that incorporates electronic programmable systems, including software, or of software that is a device in itself (section 20.4.1, point (ah)).
  • A device with a valid certificate issued under Directive 98/79/EC, or one declared to conform under that Directive without a notified body, may be placed on the market or put into service until the dates fixed in Article 110(3a) and (3b) only if the conditions of Article 110(3c) are met.
European Accessibility Act, accessibility requirements for servicessince 19 lines

Directive (EU) 2019/882, Arts. 2(2) and 13, Annex I Sections III and IV · Read the law's page

  • This duty reaches you through the law of each Member State that transposes the Directive, where you provide, or offer to provide, to consumers in the Union after an electronic communications service (other than a transmission service used for machine-to-machine services), a service providing access to audiovisual media services, the website, mobile application, electronic ticketing, travel-information or interactive self-service terminal elements of air, bus, rail or waterborne passenger transport services (for urban, suburban and regional transport services, only the interactive self-service terminals), a consumer banking service, e-books and dedicated software, or an e-commerce service (Article 2(2), Article 3(4)). A microenterprise providing services is exempt from the requirements of Article 4(3) and from any obligations relating to compliance with them (Article 4(5)); Article 3(23) defines a microenterprise as an enterprise which employs fewer than 10 persons and which has an annual turnover not exceeding EUR 2 million or an annual balance sheet total not exceeding EUR 2 million.
  • Design and provide your service in accordance with the accessibility requirements of the Directive (Article 13(1)): unless it is an urban, suburban or regional transport service it must meet Section III of Annex I, and every service must meet the part of Section IV of Annex I that applies to it (Article 4(3)).
  • Unless your service is an urban, suburban or regional transport service, make your websites, including the related online applications, and your mobile device-based services, including mobile applications, accessible in a consistent and adequate way by making them perceivable, operable, understandable and robust (Annex I, Section III, point (c)).
  • Unless your service is an urban, suburban or regional transport service, make sure the products you use to provide it meet the accessibility requirements of Section I and, where applicable, Section II of Annex I (Annex I, Section III, point (a)).
  • Unless your service is an urban, suburban or regional transport service, give information about how it works, and about the accessibility characteristics of any products used in it and their interoperability with assistive devices and facilities, through more than one sensory channel, in an understandable way and in ways users can perceive, in text formats that can be used to generate alternative assistive formats, in fonts of adequate size and suitable shape with sufficient contrast and adjustable spacing between letters, lines and paragraphs, with an alternative presentation of any non-textual content, and provide the electronic information needed to provide the service in a consistent and adequate way by making it perceivable, operable, understandable and robust (Annex I, Section III, point (b)).
  • Unless your service is an urban, suburban or regional transport service, where you provide support services such as help desks, call centers, technical support, relay services and training services, have them give information on the accessibility of the service and its compatibility with assistive technologies, in accessible modes of communication (Annex I, Section III, point (d)).
  • If you offer e-commerce services, provide the information concerning accessibility of the products and services being sold when the responsible economic operator provides it, make the functionality for identification, security and payment perceivable, operable, understandable and robust when it is delivered as part of a service instead of a product, and provide identification methods, electronic signatures and payment services that are perceivable, operable, understandable and robust (Annex I, Section IV, point (g)).
  • If you provide consumer banking services, provide identification methods, electronic signatures, security and payment services that are perceivable, operable, understandable and robust, and ensure that the information is understandable without exceeding a level of complexity superior to level B2 (upper intermediate) of the Council of Europe's Common European Framework of Reference for Languages (Annex I, Section IV, point (e)).
  • If you provide an electronic communications service, provide real time text in addition to voice communication, provide total conversation where video is provided in addition to voice, and ensure that emergency communications using voice and text, and video where provided, are synchronized and transmitted to the most appropriate public safety answering point (Annex I, Section IV, point (a)).
  • If you provide services giving access to audiovisual media services, provide electronic program guides that are perceivable, operable, understandable and robust and give information about the availability of accessibility, and ensure that subtitles for the deaf and hard of hearing, audio description, spoken subtitles and sign language interpretation are fully transmitted with adequate quality, synchronized with sound and video, with user control of their display and use (Annex I, Section IV, point (b)).
  • If you provide e-books or dedicated software, provide synchronized text and audio where an e-book contains audio in addition to text, keep e-book digital files from preventing assistive technology from operating properly, give access to the content, the navigation of the file content and layout including dynamic layout, with structure, flexibility and choice in the presentation of the content, allow alternative renditions interoperable with a variety of assistive technologies, make the e-books discoverable through metadata about their accessibility features, and do not let digital rights management measures block accessibility features (Annex I, Section IV, point (f)).
  • If you provide air, bus, rail or waterborne passenger transport services, other than urban, suburban and regional transport services, provide information on the accessibility of vehicles, the surrounding infrastructure and the built environment and on assistance for persons with disabilities, and information about smart ticketing, real-time travel information and additional service information (Annex I, Section IV, point (c)). For urban, suburban and regional transport services, make the self-service terminals used in the service accessible under Section I of Annex I (Annex I, Section IV, point (d)).
  • Include in your general terms and conditions, or an equivalent document, the information assessing how the service meets the accessibility requirements, with a general description of the service in accessible formats, the descriptions and explanations needed to understand its operation, and a description of how the relevant requirements of Annex I are met; make that information available to the public in written and oral format, including in a manner accessible to persons with disabilities, and keep it for as long as the service is in operation; and provide information demonstrating that the service delivery process and its monitoring ensure compliance (Article 13(2), Annex V, points 1 and 3).
  • Have procedures in place so that the provision of your service remains in conformity, and take adequate account of changes in the characteristics of the service, in the applicable accessibility requirements and in the harmonized standards or technical specifications by reference to which the service is declared to meet them (Article 13(3)).
  • If your service does not conform, take the corrective measures necessary to bring it into conformity and immediately inform the competent national authorities of the Member States in which the service is provided, giving details of the non-compliance and of the corrective measures taken (Article 13(4)). On a reasoned request from a competent authority, provide all the information necessary to demonstrate conformity and cooperate on any action taken to bring the service into compliance (Article 13(5)).
  • You may rely on fundamental alteration or disproportionate burden only to the extent that compliance would require a significant change that results in the fundamental alteration of the basic nature of the service or would impose a disproportionate burden. Carry out an assessment of either ground, judging disproportionate burden against the criteria in Annex VI, document it, keep all relevant results for five years from the day the service was last provided, give a copy of the assessment to the authorities responsible for checking compliance of services on request, and send information that you rely on this ground to those authorities of the Member State where the service is provided (Article 14(1), (2), (3) and (8)). If you rely on disproportionate burden, renew that assessment for each category or type of service when the service is altered, when those authorities ask, and in any event at least every five years (Article 14(5)). You cannot rely on disproportionate burden where you receive funding, public or private, from other sources than your own resources that is provided for the purpose of improving accessibility (Article 14(6)).
  • The Directive does not apply to the following content of websites and mobile applications: pre-recorded time-based media and office file formats published before , online maps and mapping services if essential information is provided in an accessible digital manner for maps intended for navigational use, third-party content that is neither funded, developed by, or under the control of the economic operator concerned, and archives that only contain content not updated or edited after (Article 2(4)).
  • Member States provide for a transitional period ending on during which you may continue to provide your service using products you lawfully used to provide similar services before that date, and service contracts agreed before may continue without alteration until they expire, but no longer than five years from that date; a Member State may also let you keep using self-service terminals you lawfully used to provide services before until the end of their economically useful life, but no longer than 20 years after their entry into use (Article 32(1) and (2)).
  • If you provide air, bus, rail or waterborne passenger transport services, a service that complies with the requirements on accessible information and on information on accessibility of Regulations (EC) No 261/2004, (EC) No 1107/2006, (EC) No 1371/2007, (EU) No 1177/2010 and (EU) No 181/2011 is deemed to comply with the corresponding requirements of the Directive, and the Directive's additional requirements apply in full (Article 5).
Data Act, User Access to Connected-Product Data and Sharing with Third Parties (Articles 3 to 5)since 19 lines

Regulation (EU) 2023/2854, Arts. 3-5 · Read the law's page

  • For connected products, and the services related to them, placed on the market after (Article 50), design and manufacture the connected product, and design and provide the related service, so that product data and related service data, including the relevant metadata necessary to interpret and use those data, are by default easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format and, where relevant and technically feasible, directly accessible to the user (Article 3(1)).
  • Before concluding a contract for the purchase, rent or lease of a connected product, and as the seller, rentor or lessor (which may be the manufacturer), give the user in a clear and comprehensible manner at least the type, format and estimated volume of product data the product is capable of generating, whether it is capable of generating data continuously and in real-time, whether it is capable of storing data on-device or on a remote server (with the intended duration of retention, where applicable), and how the user may access, retrieve or, where relevant, erase the data, including the technical means and the terms of use and quality of service (Article 3(2)).
  • Before concluding a contract for the provision of a related service, and as the provider of the related service, give the user in a clear and comprehensible manner at least the information listed in Article 3(3), points (a) to (i), among them the nature, estimated volume and collection frequency of the product data the prospective data holder is expected to obtain, whether it expects to use readily available data itself and for which purposes, how the user can request that the data are shared with a third party, the user's right to lodge a complaint with the competent authority designated under Article 37, and the duration of the contract and the arrangements for terminating it (Article 3(3)).
  • Where data cannot be directly accessed by the user from the connected product or related service, make readily available data, as well as the relevant metadata necessary to interpret and use those data, accessible to the user without undue delay, of the same quality as is available to the data holder, easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format and, where relevant and technically feasible, continuously and in real-time, on the basis of a simple request through electronic means where technically feasible (Article 4(1)).
  • Do not make the exercise of choices or rights under Article 4 by the user unduly difficult, including by offering choices to the user in a non-neutral manner or by subverting or impairing the autonomy, decision-making or choices of the user via the structure, design, function or manner of operation of a user digital interface or a part thereof (Article 4(4)).
  • To verify whether a person qualifies as a user, do not require that person to provide any information beyond what is necessary, and do not keep any information, in particular log data, on the user's access to the data requested beyond what is necessary for the sound execution of the user's access request and for the security and maintenance of the data infrastructure (Article 4(5)).
  • Identify the data protected as trade secrets, including in the relevant metadata, and agree with the user the proportionate technical and organizational measures necessary to preserve the confidentiality of the shared data, in particular in relation to third parties (Article 4(6)).
  • Where the data holder refuses to share data pursuant to Article 4, notify the competent authority designated under Article 37 (Article 4(2)); where the data holder withholds or suspends the sharing of data identified as trade secrets (Article 4(7)), or refuses a request on the ground of serious economic damage from the disclosure of trade secrets (Article 4(8)), also give the user a duly substantiated decision in writing without undue delay (Article 4(7) and (8)).
  • Where the user is not the data subject whose personal data is requested, make personal data generated by the use of a connected product or related service available to the user only where there is a valid legal basis for processing under Article 6 of Regulation (EU) 2016/679 and, where relevant, the conditions of Article 9 of that Regulation and of Article 5(3) of Directive 2002/58/EC are fulfilled (Article 4(12)).
  • Use readily available data that is non-personal data only on the basis of a contract with the user, and do not use it to derive insights about the economic situation, assets and production methods of, or the use by, the user in any other manner that could undermine the commercial position of that user on the markets in which the user is active (Article 4(13)).
  • Do not make non-personal product data available to third parties for commercial or non-commercial purposes other than the fulfillment of the data holder's contract with the user, and where relevant contractually bind third parties not to further share the data received (Article 4(14)).
  • Upon request by a user, or by a party acting on behalf of a user, make readily available data, as well as the relevant metadata necessary to interpret and use those data, available to a third party without undue delay, of the same quality as is available to the data holder, easily, securely, free of charge to the user, in a comprehensive, structured, commonly used and machine-readable format and, where relevant and technically feasible, continuously and in real-time, in accordance with Articles 8 and 9 (Article 5(1)).
  • Treat an undertaking designated as a gatekeeper pursuant to Article 3 of Regulation (EU) 2022/1925 as not an eligible third party under Article 5 (Article 5(3)).
  • To verify whether a person qualifies as a user or as a third party, do not require that person to provide any information beyond what is necessary, and do not keep any information on the third party's access to the data requested beyond what is necessary for the sound execution of the third party's access request and for the security and maintenance of the data infrastructure (Article 5(4)).
  • Do not use any readily available data to derive insights about the economic situation, assets and production methods of, or the use by, the third party in any other manner that could undermine the commercial position of the third party on the markets in which the third party is active, unless the third party has given permission to such use and has the technical possibility to easily withdraw that permission at any time (Article 5(6)).
  • Where the user is not the data subject whose personal data is requested, make personal data generated by the use of a connected product or related service available to the third party only where there is a valid legal basis for processing under Article 6 of Regulation (EU) 2016/679 and, where relevant, the conditions of Article 9 of that Regulation and of Article 5(3) of Directive 2002/58/EC are fulfilled (Article 5(7)).
  • Do not let a failure to agree with the third party on arrangements for transmitting the data hinder, prevent or interfere with the exercise of the rights of the data subject under Regulation (EU) 2016/679, in particular the right to data portability under Article 20 of that Regulation (Article 5(8)).
  • Identify the data protected as trade secrets, including in the relevant metadata, agree with the third party all proportionate technical and organizational measures necessary to preserve the confidentiality of the shared data, and disclose trade secrets to third parties only to the extent that disclosure is strictly necessary to fulfill the purpose agreed between the user and the third party (Article 5(9)).
  • Where the data holder withholds or suspends the sharing of data identified as trade secrets (Article 5(10)), or refuses a request on the ground of serious economic damage from the disclosure of trade secrets (Article 5(11)), give the third party a duly substantiated decision in writing without undue delay and notify the competent authority designated under Article 37 (Article 5(10) and (11)).
Commission Implementing Regulation (EU) 2025/2392, Technical Description of Important and Critical Products with Digital Elementssince 4 lines

Regulation (EU) 2025/2392, Art. 2 and Annexes I and II · Read the law's page

  • This classification reaches you where you are a manufacturer placing on the EU market a product with digital elements whose core functionality meets a technical description in Annex I (important products, class I or class II) or Annex II (critical products), under Regulation (EU) 2024/2847.
  • Decide by your product's core functionality, not by an incidental or integrated function, whether it meets a technical description: a product that performs additional functions can still have the core functionality of a category, and a product that can perform a category's functions but has a different core functionality does not meet that description (recitals 4 and 5).
  • Where a component of your product meets a technical description, classify the product as a whole rather than treating the whole product as important or critical on that account, and still demonstrate that the whole product, including the integrated component, meets the essential cybersecurity requirements (Article 7(1) of Regulation (EU) 2024/2847 and recital 3).
  • Demonstrate conformity of a product that meets a description in Annex I through the procedures of Article 32(2) and (3) of Regulation (EU) 2024/2847, and of a product that meets a description in Annex II through Article 32(4) of that Regulation.
Cyber Resilience Act, Manufacturer Reporting Obligationssince 5 lines

Regulation (EU) 2024/2847, Art. 14 · Read the law's page

  • The reporting obligations of Article 14 apply to a product with digital elements from .
  • Notify the CSIRT designated as coordinator for your main establishment and ENISA, through the single reporting platform, of any actively exploited vulnerability you become aware of in your product: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure becomes available, the notification and the final report each unless the relevant information has already been provided.
  • Notify the same recipients of any severe incident affecting the security of your product on the same 24-hour early warning and 72-hour incident notification clock, followed by a final report within one month of the incident notification; the incident notification and the final report each apply unless the relevant information has already been provided. For either an exploited vulnerability or a severe incident, give the CSIRT an intermediate report on relevant status updates if it asks for one.
  • After becoming aware of the vulnerability or incident, inform the affected users, and where appropriate all users, of it and of any risk mitigation or corrective measures they can take.
  • Apply this to every product with digital elements within the Regulation's scope that you have on the EU market, including one placed there before , because Article 69(3) exempts Article 14 from the transitional rule that spares existing products until they are substantially modified. Article 2 leaves out, among others, products covered by Regulations (EU) 2017/745, (EU) 2017/746 and (EU) 2019/2144, products certified under Regulation (EU) 2018/1139, equipment within Directive 2014/90/EU, spare parts that replace identical components, and products developed or modified exclusively for national security or defence purposes.
Product Liability Directive, liability for defective products including softwarefrom , in 4 weeks10 lines

Directive (EU) 2024/2853 · Read the law's page

  • The Directive does not apply to free and open-source software that you develop or supply outside the course of a commercial activity (Art. 2(2)).
  • If you develop or produce software, or have it developed under your name or trademark, and make it available in the course of a commercial activity, you answer as its manufacturer for damage it causes by a defect (Arts. 4(1), 4(10) and 8(1)(a)).
  • Keep supplying the software updates and upgrades needed to keep the product safe while it is within your control; a defect caused by their absence, or by software, updates or upgrades within your control, is not excused because it arose after you placed the product on the market (Art. 11(2)(b) and (c)).
  • Meet the product safety requirements that apply to your product, safety-relevant cybersecurity requirements included: they count in deciding whether it is defective (Art. 7(2)(f)), and failing a mandatory product safety requirement that protects against the damage suffered presumes it defective (Art. 10(2)(b)).
  • Account for what your product learns or acquires after release: the effect of any ability to continue to learn or acquire new features after it is placed on the market is weighed in deciding whether it is defective (Art. 7(2)(c)).
  • Keep technical documentation you could produce if a court orders disclosure; failing to disclose presumes the product defective (Arts. 9(1), 10(2)(a)).
  • If you are outside the EU, the importer or your authorized representative answers for the product in your place (Art. 8(1)(c)).
  • If you substantially modify a product outside its manufacturer's control and then make it available on the market or put it into service, you are treated as its manufacturer (Art. 8(2)).
  • Do not count on a contract term to limit or exclude your liability to an injured person; Article 15 bars it.
  • Be able to show when you placed the product on the market or put it into service: you are not liable if you prove you did not, or that the defect probably did not exist at that time (Art. 11(1)(a) and (c)).
Machinery Regulation, Protection Against Corruption and Safety and Reliability of Control Systems (Software and Cybersecurity Requirements)from , in 2 months9 lines

Regulation (EU) 2023/1230, Annex III, sections 1.1.9 and 1.2.1 · Read the law's page

  • This duty takes effect on (Article 54 of Regulation (EU) 2023/1230), when Directive 2006/42/EC is repealed (Article 51(2)).
  • It reaches you if you are a manufacturer, meaning a person that makes machinery or a related product and markets it under its name or trademark, or puts it into service for its own use, and you place that product on the EU market or put it into service; a safety component can be a digital component, including software, that is independently placed on the market to fulfil a safety function: design and construct the product in accordance with the essential health and safety requirements of Annex III (Articles 2(1), 3, point (3), and 10(1)); sections 1.1.9 and 1.2.1 hold its provisions on protection against corruption of software and data and on malicious third-party influence on control systems.
  • Design and construct the product so that connecting another device, through a feature of that device or a remote device that communicates with it, does not lead to a hazardous situation (section 1.1.9).
  • Design a hardware component that transmits signal or data relevant for connection or access to software critical for compliance so that it is adequately protected against accidental or intentional corruption, and identify software and data critical for compliance as such and protect them adequately against accidental or intentional corruption (section 1.1.9).
  • Make the product identify the software installed on it that is necessary for it to operate safely and provide that information at all times in an easily accessible form, and collect evidence of a legitimate or illegitimate intervention in that hardware component, in the software, or in a modification of the software or its configuration (section 1.1.9).
  • Design and construct control systems so that they can withstand, where appropriate to the circumstances and the risks, the intended operating stresses and intended and unintended external influences, including reasonably foreseeable malicious attempts from third parties leading to a hazardous situation (section 1.2.1, point (a)).
  • Enable a tracing log of the data generated in relation to an intervention, and of the versions of safety software uploaded after the product is placed on the market or put into service, for five years after each upload, exclusively to demonstrate conformity further to a reasoned request from a competent national authority (section 1.2.1, point (f)).
  • For control systems with fully or partially self-evolving behavior or logic designed to operate with varying levels of autonomy, enable the recording of data on the safety related decision-making process of software based safety systems, retain it for one year after its collection, and make it possible at all times to correct the product to maintain its inherent safety (section 1.2.1).
  • The Regulation does not apply to, among others, motor vehicles within the scope of Regulation (EU) 2018/858, except for machinery mounted on them, or to household appliances, audio and video equipment and information technology equipment insofar as they fall within Directive 2014/35/EU or Directive 2014/53/EU (Article 2(2), points (g) and (p)).
Cyber Resilience Act, Essential Requirements and Manufacturer Obligationsfrom , in 13 months5 lines

Regulation (EU) 2024/2847, Art. 13 and Annex I · Read the law's page

  • The Regulation does not reach free and open source software that is not monetized by its manufacturer (monetizing covers charging for the software, charging for technical support beyond recovering costs, providing a platform through which you monetize other services, requiring personal-data processing as a condition of use for reasons other than security, compatibility or interoperability, and accepting donations that exceed costs), or a remote data processing service the product does not need in order to perform one of its own functions.
  • Design, develop, and produce the product, on the basis of your cybersecurity risk assessment and where each requirement applies, so it ships without known exploitable vulnerabilities, with a secure default configuration (unless you agree otherwise with a business user for a tailor-made product), protection against unauthorised access, and protection of the confidentiality of stored, transmitted or otherwise processed data, such as by encrypting relevant data at rest or in transit.
  • Maintain a support period of at least five years, or the product's expected use time if shorter, handle vulnerabilities in the product and its components throughout that period, and keep each security update available for ten years after release or for the remainder of the support period, whichever is longer.
  • From (Article 71(2)), when you identify a vulnerability in a component integrated in your product, including an open-source component, report the vulnerability to the person or entity manufacturing or maintaining the component and address and remediate it under the vulnerability handling requirements of Annex I, Part II. If you developed a software or hardware modification to address the vulnerability, share the relevant code or documentation with that person or entity, where appropriate in a machine-readable format (Article 13(6)).
  • Put in place a coordinated vulnerability disclosure policy and a contact channel for reporting a vulnerability, and disclose the end date of the support period to the buyer at the time of purchase.
European Health Data Space Regulation, Essential Requirements for the Harmonised Software Components of EHR Systemsfrom , in 2.4 years9 lines

Regulation (EU) 2025/327, Art. 30(1)(a) and Annex II · Read the law's page

  • This duty takes effect on for EHR systems intended by the manufacturer to process the priority categories of personal electronic health data in Article 14(1), points (a), (b) and (c), and on for those intended to process points (d), (e) and (f) and for EHR systems put into service under Article 26(2): Article 105 applies the Regulation from but applies Articles 25 to 27, which govern placing an EHR system on the market, and Chapter III for Article 26(2) systems from those later dates, and the manufacturer's Article 30 duty attaches to a system placed on the market under them.
  • It reaches you if you are the manufacturer of an EHR system, meaning software, or hardware and software together, that stores, intermediates, exports, imports, converts, edits or views personal electronic health data of the priority categories and is intended for use by healthcare providers giving patient care or by patients accessing their own data, including a system manufactured and used within a health institution and a system offered as a service (Article 2, point (k), and Article 26(2)); general purpose software used in a healthcare environment is outside Chapter III (Article 25(2)). Ensure that the harmonised software components of your EHR systems, the European interoperability software component and the European logging software component, and the EHR systems themselves to the extent Chapter III sets requirements for them, conform with the essential requirements in Annex II and with the common specifications adopted under Article 36 (Article 30(1), point (a)).
  • Design and develop your EHR system so that its interoperability, safety and security features uphold the rights of natural persons, and so that, where it is operated together with other products including medical devices, the harmonised software components make interoperability and compatibility reliable and secure (Annex II, points 1.3 and 1.4).
  • Provide reliable mechanisms for the identification and authentication of health professionals in an EHR system designed to be used by health professionals (Annex II, point 3.1).
  • Have the European logging software component of an EHR system designed to enable access to personal electronic health data record at least, on every access event or group of events, the identification of the healthcare provider or other individuals who accessed the data, the identification of the specific natural person or persons who accessed it, the categories of data accessed, the time and date of access and the origin or origins of the data (Annex II, point 3.2).
  • Include in the harmonised software components tools or mechanisms to review and analyze the log data, or support the connection and use of external software for the same purposes, and support different retention periods and access rights that take into account the origins and categories of electronic health data (Annex II, points 3.3 and 3.4).
  • Provide, where the EHR system is designed to store or intermediate personal electronic health data, an interface enabling access to that data in the European electronic health record exchange format and the ability to receive it in that format; where it is designed to provide access to such data, be able to receive it in that format; and where it includes a functionality for entering structured data, enable entry with sufficient granularity to provide the entered data in that format (Annex II, points 2.1 to 2.4).
  • Do not include in the harmonised software components features that prohibit, restrict or place an undue burden on authorized access, sharing or use of personal electronic health data for permitted purposes, or on authorized export of that data for the purpose of replacing the EHR system by another product (Annex II, points 2.5 and 2.6).
  • If you make a wellness application, a medical device, an in vitro diagnostic medical device or an AI system and claim interoperability with EHR systems, meet the Annex II essential requirements mutatis mutandis (Annex II, introductory sentence).
European Health Data Space Regulation, Serious-Incident Reporting by Manufacturers of EHR Systemsfrom , in 2.4 years4 lines

Regulation (EU) 2025/327, Art. 44(7) · Read the law's page

  • This duty takes effect on for EHR systems intended by the manufacturer to process the priority categories of personal electronic health data in Article 14(1), points (a), (b) and (c), and on for those intended to process points (d), (e) and (f): Article 105 applies the Regulation from but applies Articles 25 to 27, which govern placing an EHR system on the market, from those later dates, and the Article 44(7) report concerns a system placed on the market under them.
  • It reaches you if you are the manufacturer of an EHR system placed on the market or put into service. Report any serious incident (Article 2, point (r)) involving the EHR system to the market surveillance authorities of the Member States where the serious incident occurred and of the Member States where the system is placed on the market or put into service, and include a description of the corrective action you have taken or envisage (Article 44(7)).
  • Make the report immediately after you have established a causal link between the EHR system and the serious incident or the reasonable likelihood of such a link and, in any event, not later than three days after you become aware of the serious incident (Article 44(7)).
  • Make the report without prejudice to any incident notification that Directive (EU) 2022/2555 requires of you (Article 44(7)).

Revisions

An entry gets a new revision when a law in it is added, removed, amended or reworded in the law library. The ID stays the same.

  1. Revision 1, : the entry was first published.

See also

Page updated .