The Cyber Resilience Act, or CRA, is a new legislation that aims to establish new cybersecurity requirements for devices and software marketed in the European Union.
But what impact can the CRA have in terms of video game development, and more specifically, what impact can it have on Godot or your game if you consider selling it in any European country?
In this article I am going to try to delve a little deeper into this topic, but, before going into detail, I would like to clarify two things:
First: at the time of writing this article, all we know is what is written in a draft of this new law, so everything discussed here is subject to change.
Second: I am not a legal expert, I am simply going to try to explain in simple terms what I have been able to find out and give my opinion about how it could affect the video game development industry.
So without further ado let's try to figure out what CRA is, and what impact it could have on Godot and in games published in the EU.
What is the Cyber Resilience Act, or CRA?
Introduced by the European Union, the CRA seeks to elevate cybersecurity standards for digital devices and software intended for the EU market.
Both manufacturers and developers who market devices or software in the European Union, without taking into account their global location, must ensure the security of such digital products so they reach the market with fewer vulnerabilities and ensure that relevant quality standards are taken seriously. In addition, it's also intended that users can take this quality into account when consuming products with digital elements.
A significant shift of the CRA is its focus on software developers rather than the companies that use this software. The rationale? Developers are in a prime position to address vulnerabilities at their source, making software inherently safer.
However, not all software is seen as equal under the CRA. Based on its use and potential risks, software is divided into three categories.
Non-critical products: It is estimated that the vast majority of products will be in this group. In my opinion, both Godot and video games would fall into this group.
Critical Class 1: This level includes software with higher-risk functions such as password managers, VPNs, network management systems, or remote access software.
Critical Class 2: Reserved for products that have the highest level of risk: operating systems, public key infrastructure and digital certification, general-purpose microprocessors or routers.
Depending on its classification, software may face varying obligations. These range from comprehensive risk assessments to ensure software doesn't have known vulnerabilities and is configured for security by default, to extensive documentation detailing the product's design, vulnerabilities, and compliance with EU cybersecurity standards.
Additionally, while non-critical software developers can self-certify their products, those in the Critical Class categories must undergo assessments by external EU-certified auditors.
When vulnerabilities are detected, especially those under active exploitation, developers have a tight 24-hour window to report them to the European Union Agency for Cybersecurity.
Now that we have a general idea about what the CRA is and what new obligations it imposes, let's see what impact it can have on Godot and games released in European territory.
How will the CRA impact Godot and games published in the EU?
In my opinion, based on the three groups of products discussed above, everything would seem to indicate that both video game engines and the video games themselves would fall within the group of non-critical products; given that its impact in terms of risk seems to be less pronounced than the products considered critical by this new rule.
But even as a non-critical product, both the Godot development team and any video game maker might not be exempt from the obligations that the CRA imposes. This act implies that developers, even of non-critical software, carry out a compliance self-assessment.
This self-assessment is essentially a commitment to ensure that their software complies with the cybersecurity standards outlined by the CRA. It means ensuring there are no known vulnerabilities, providing security patches, and maintaining a secure by default approach.
However, given the open-source nature of Godot, much like other free projects, this can generate additional complexities. This is because this type of software is distributed freely, without exhaustive control of who it is distributed to or for what reasons, therefore it can be harmful to impose this level of obligations on someone who simply delivers software freely without any type of cost.
For other open-source projects considered higher risk such as Linux distributions, the implications of the CRA could be more profound. Given their consideration as critical products, these projects could face much stricter regulations; which could discourage a company from delivering software as free software given this level of complexity and responsibility.
So far, everything seems to indicate that those projects considered "non-commercial" would be exempt from this rule, however, there are those who consider that an open-source project, if it receives financing even through donations on a regular basis, could be considered as commercial software and would have to comply with the CRA. Without a doubt Godot, given that it is frequently financed through altruistic donations, could fall into this group if this were confirmed.
As for video games marketed in Europe, they would undoubtedly also fall within the scope of the CRA as non-critical products, so they would be under the obligations discussed above.
Conclusion
As we reach the end of our deep dive into the CRA's potential implications, it's essential to remember that what we've discussed is based on the current draft of the act.
This means the provisions, classifications, and requirements can still change before the act is finalized and put into effect. The legislative process is both dynamic and responsive, and feedback from stakeholders, including the open-source community, can shape the final form of the act.
Throughout our exploration, we've uncovered the potential challenges the Godot team might face, from the intricacies of self-assessments to the added layers brought on by its open-source nature. But with every challenge, there lies an opportunity.
In this context, it’s an opportunity for the Godot community to rally together, employ enhanced security practices, and continue producing the remarkable software that countless developers rely on.
We'll continue to watch the development of the CRA, always hopeful and confident that the spirit of open-source collaboration will thrive, adapt, and lead the way into a secure, innovative future.
