Are you ready for Europe's Cybersecurity Regulation Act?

Webinar Transcript: How to Prepare for the EU’s Cyber Resilience Act

Learn more about NXM’s CRA pre-compliance audit.

Divya Allen (00:04):

Hello. Welcome, everybody. Thank you for your patience. We will just wait a minute to allow more attendees to join in before we get started.

(01:09):

Good morning everyone, and welcome to the webinar on preparing for the EU Cyber Resilience Act. Thank you for being here. My name is Divya Allen, marketing strategist at NeuronicWorks Inc., and I'll be moderating today's session. Just a little housekeeping before we get started. Please keep yourself on mute throughout the duration of the webinar. If you have any questions for our presenters, please type them into the chat box and they will be answered at the end of the presentation. This session today is being recorded, and will be made available to all attendees. Now without further ado, let me introduce our presenters for today.

(01:47):

We have with us our guest speaker, Kevin Oerton, who's the Chief Product Officer at NXM Labs. NXM Labs is the leader in autonomous security software solutions for embedded devices. Kevin brings 25 years of experience in product strategy and development, marketing, and business operations, with extensive experience in semiconductors, communications, security, mobile and cloud software development. At our end we have Titu Botos, CEO and co-founder of NeuronicWorks. Titu will be filling in for Chris, who could unfortunately not make it for this event. Titu has over 30 years of experience in analysis, design, testing, and debugging of both analog and digital systems. And has a strong background in engineering research and training.

(02:32):

Today's presentation will be about how the European Union is on track to begin holding IoT device manufacturers accountable for mismanagement, loss, corruption, or misuse of third party data. The initial part of the presentation will be covered by Kevin, from NXM, where he'll explain the new Cyber Resilience Act, its impact and obligations of market players. The second part will be covered by Titu, where he explains the key security considerations at each stage of the product development process. Now over to you Kevin.

Kevin Oerton (03:05):

Great. Thank you, Divya. All right. To start off with, I wanted to give some rather astounding statistics on the size of the problem that we're talking about here. If you measured cyber crime as a GDP, cyber crime would rank as the world's third largest economy after the US and China. It's expected to reach a staggering 10.5 trillion US dollars annually by 2025, and that's up from 6 trillion US dollars in 2021. This represents the greatest transfer of economic wealth in history. It's exponentially larger than the damage inflicted by natural disasters, and will be more profitable than the global trade of all major illegal drugs combined.

(03:57):

And this damage cost estimation is based on two factors. The first is a dramatic increase in hostile nation state sponsored and organized crime gang related hacking activities. And second, a much greater cybersecurity attack surface area, driven in large part by the growth of the IoT industry. And so some of the major contributors to these costs include the damage and destruction of data, lost productivity, theft of intellectual property, theft of personal data, post-attack disruption to the normal course of business, the forensic investigation which needs to happen to discover what happened, and then the restoration and deletion of hacked data and systems. And then finally, the reputational harm to the manufacturer.

(04:58):

What is this new EU Cyber Resilience Act, or CRA for short? The IoT segment has grown rapidly of course, and with it have come many examples of vulnerable products. You now have many types of devices becoming internet connected. And generally, security has been lagging behind. For example, products are still using older generation hardware chips, silicon that lack hardware-based security. Manufacturers are unable to efficiently keep track of all of the security vulnerabilities that may be present in their software. Manufacturers are unable to provide regular security updates, and lack strong update mechanisms. And vulnerabilities caused by the use of passwords provide a convenient entry point for hackers. So this very short list is just a partial subset of things that the EU CRA Act intends to clean up.

(06:02):

And so, in response to all of this, on September 15th the EU did in fact publish a proposal for a Cyber Resilience Act. And this regulation targets any software or hardware product and its remote data processing solutions. This means both your physical product, which is comprised of hardware and software, as well as any related software that works with your product, be it on the cloud or in the form of user applications. And so manufacturers will need to comply with a minimum set of cybersecurity requirements to place that product on the EU market.

(06:46):

Why is it being published now? Well, we already saw the size of the cyber crime economy. And we already know that hardware and software products are increasingly subject to successful cyber attacks. Basically, products suffer from two major problems which are adding cost to borne specifically by end-users and to the EU society in general. Number one, low levels of cybersecurity are reflected by widespread vulnerabilities, and insufficient or inconsistent provision of security updates to address them. And two, insufficient understanding and access to information by users which prevents them from choosing products with adequate cybersecurity. And of course, in a connected environment, a cybersecurity incident in one product can affect an entire organization or a whole supply chain, and this can lead to severe disruption of economic and social activities, or even become life threatening in some cases.

(08:01):

And so attacks are growing in number and complexity. The EU has an agency for cybersecurity called ENISA, which publishes an annual threat landscape report. And in the 2022 report they identify prime threats, major trends, threat actors, and attack techniques, as well as mitigation measures. And so for '22, some of the top threats that they've identified include ransomware, where 60% of affected organizations may have paid ransom demands. Malware, where 66 disclosures of so-called zero-day vulnerabilities were observed in 2021. A zero-day vulnerability is a security flaw that can be exploited by attackers through the release of malware before a developer has had an opportunity to create a patch to fix the vulnerability. Hence zero-day.

(08:59):

Social engineering, include phishing scams where they try to get you to click a link and enter personal information remains a popular technique, but new forms of phishing are on the rise. Threats against data, which are increasing in proportion to the total data produced. And threats against availability, where denial of service attacks are getting larger and more complex, and are moving towards mobile networks as well as IoT platforms which are now being used in cyber warfare. This information, aided by AI enabled mechanisms, is enabling deep fakes and even "Disinformation-as-a-Service" platforms making their appearance. And then finally, supply chain targeting, where third party incidents now account for 17% of total attacks compared to less than 1% in 2020.

(10:02):

What are the new obligations that manufacturers of IoT devices will need to meet in order to be compliant with CRA? Well, first is cybersecurity, which calls for security by design. And this impacts all phases of the product lifecycle from planning, design, development, all the way through to production, delivery, and the maintenance phase of that product. And the CRA requirements reflect common principles underlying information security best practices. And since IoT covers many different platforms, including the device itself, along with related end-user applications and cloud processing, you now have to understand and implement proper security on each of these platforms wherever data is processed. It also regulates in the area of consumer privacy and data sharing with third parties. And so as a manufacturer, if you have a business model that sees you sharing consumer personal data with third parties, then you'll now begin to need consumer affirmative consent to do so.

(11:12):

You'll also need to ensure that the third party service providers uphold the same privacy and data handling policies that you need to meet as a manufacturer. Such as holding data in confidence and notification to the consumers of any data loss or data breaches. There's also the concept of "lifetime product support". And what this means, is that when you place a product on the market, you need to communicate to the purchaser your intended support period for that product. And so minimally, this needs to be either five years. Or if the product has a particularly short lifetime, it can be less than that.

(12:00):

However, manufacturers will need to ensure that all vulnerabilities for that product are handled effectively. To do this, you'll need to draw up a software "bill of materials" which covers at least the top level components that exist in the software. And as vulnerabilities come up, you'll need to address and remedy them on a expedited basis, and you'll also need to provide a contact address for the reporting of discovered vulnerabilities. And once a security update becomes available, you'll need to publicly disclose information about what vulnerabilities have been fixed and how to obtain the update.

(12:43):

Cybersecurity information also comes into play where manufacturers will have reporting obligations in relation to actively exploited vulnerabilities, on the one hand, and security incidents on the other. And any incident having an impact on the security of the product needs to be reported within 24 hours of becoming aware of it, which is not much time at all. And you'll need to inform users, where necessary, about corrective measures that the user can deploy to mitigate the impact of the incident. Also, before placing your product on the market, you'll need to complete a conformity assessment. This needs to be undertaken by manufacturers to ensure that your product complies with all of the CRA security requirements. And you'll need to drop technical documentation and ensure that your product is fully compliant with the CRA as part of the CE marking that you'll need to continue to apply to the device.

(13:54):

The obligations here also extend beyond the manufacturer to also include distributors and importers. And because importers and distributors are involved in placing products on the EU market, they will minimally need to ensure that your documentation includes the declaration of conformity and CE markings. And if the importer or distributor markets the product under their own name or trademark, they will be subject to the same obligations as the manufacturer. If an in-market product falls out of compliance, the distributor may be directed to withhold further product sales until it is brought back into compliance. Or in a worse case, it could be asked to comply with a product recall. To make all of this enforceable, the EU will be working with individual national authorities where each EU country will appoint a market surveillance authority, and they will be responsible for enforcement of these obligations.

(15:04):

What happens to non-compliant products? Well, like other recent legislation from the EU, such as the GDPR, which regulates privacy, this regulation proposes tough penalties to ensure compliance. Non-compliance can lead to recall or withdrawal of the product from the market, or another corrective action. But it can also lead to fines of up to 15 million euro, or 2.5% of the manufacturer's total worldwide revenue, whichever is higher. And so what are the regulatory timelines? Well, the proposed regulation has already undergone a significant amount of due diligence up until this point. The commission has consulted with a broad range of stakeholders, including national market surveillance authorities, EU bodies dealing with cybersecurity, hardware and software manufacturers, importers and distributors, trade associations, product users and citizens, as well as industry cybersecurity experts. These stakeholders were invited to participate in open public consultation and in surveys and in workshops.

(16:18):

And the commission conducted an impact assessment, which was reviewed on July 6th, a couple months ago, with the commission's regulatory scrutiny board. And it's this board that basically says whether a proposed new regulation has met the level of criteria such that it's ready to be presented, which it did. So, in September the commission presented the proposal to the EU parliament, which is currently under review. And so once it passes from draft into law, manufacturers will have one year to begin vulnerability reporting on then in-market products, and then two years to bring all in-market products into full compliance.

(17:14):

This is the EU declaration of conformity, the set of items that need to be included in this declaration. And you can see that an officer from the company will have to sign on the dotted line. And products that bear the CE mark are indicating their conformity with this new regulation. At this point, I'd like to hand things over to Titu to provide more detail on how Neuronic can help you prepare for this new regulation, and to explain what that process might look like. Thank you.

Titu Botos (17:52):

Thank you very much. I hope you can hear me. I will start by presenting what you can expect by working with us. And here I like to address the platform that NXM is offering as a solution for this new act. Is a feature full rounded platform that, as you can see on the slide, has a series of features to help not only create a new product, but then maintain and keep it on the market. If we go through quickly here, we have features like privacy, integrity, and availability. Here, I can give you example of the zero trust when we can assure that no IoT device and users can be automatically trusted, they have to authenticate themselves. And not only once, but be continuously authenticated and authorized and validated for a correct secure posture.

(18:58):

Obviously, future for access control. There are powerful admin capabilities to ensure that only authorized users can access IoT data and services. And to make sure also that this functionally is working across consumer, commercial and industrial environments. It's a big umbrella to cover here. We have to be mindful of the secure supply chain, and with that, the platform developed by NXM is integrating with existing factory processes to securely provision firmware and security credentials. It keeps tracks of the software components that go into the given firmware or software release. If a vulnerability is discovered, the platform can easily identify impacted endpoints and push a new release.

(19:57):

The platform will help you, as our customer, to a fast track for Cyber Resilience Act compliance. We'll accelerate the compliance by working with security certified chips, operating systems, and NXM security libraries. Also, it is easy to maintain from the CRA Cyber Resilience Act compliance point of view. Provides a full device lifecycle security management, provides vulnerability management and reporting. And as equal as important, security monitoring responses and recovery. We believe it's easy to implement, and we definitely can help you there. It's easy to use and avoids vendor lock, meaning, we support multiple devices, user and cloud platforms, and can be switched in between them. That give the advantage that the product can be over time using different chips, different cloud providers. We are therefore flexible.

(21:17):

A security by design approach, we will focus on security aspects of the future product at an early stage of design and development process rather than addressing issues reactively. If I may, I like to make a parallel with certification and compliance of your product with, for example, FCC, or PTCRB, things that our clients may be more familiar with. Even in those cases, it is best to address the compliance to certain standards from the beginning of the design cycle, design process, rather than finding yourself at the end the final testing for the certification failing and have to start again. So similarly, design for cybersecurity has to start from the first stages of the product development process. Now, obviously I'm speaking from a hardware perspective because, yes, I'm still a hardware engineer at heart. It is particularly important for hardware based products.

(22:28):

Why? Because silicon cannot be patched in the same way the firmware and software can be patched. Shipping a product with hardware, security weakness can have catastrophic long-term consequences. And we'll touch about recalls toward the end of my presentation here. Let's look at the security considerations at each stage of the product development process related to the Cybersecurity Resilience Act. And what you see on your screen right now, it's a very high level three phase process. We have a product definition, we call that nicely the Fuzzy Front End. We go to the product development with engineering design and development, and then commercialization, that adds together manufacturing and operations.

(23:19):

Let's start with the first phase, that is the marketing analysis and business decision of what the new product should be. This part of this product development process, it's not covered by our presentation, it's not necessarily is touched by this compliance with Cybersecurity Resilience Act, and we will jump into the next one. And that is the concept phase. Now, this is a stage when one has to identify the industry specific security compliance and regulations that the new device should meet. Simply put, one has to ask herself/himself, what security certifications do we do or need for my new product?

(24:12):

The answer to this question, it can be quite laborious and quite long. For example, requirements can range from lows. Such Health Insurance Portability and Accountability Act, the HIPAA Act. It can go up to industry mandates such as PCI DSS regulations, which guide how companies process credit card and payments. Another example for this type of laws and requirements can be the general data protection regulation that governs the treatment of personal data for citizens of the European Union. Again, we see EU at the forefront of these concerns addressing these concerns through regulations. And I want to point out here, and please pay attention, that even if your company is not located in EU, you might be subject to these regulations, similar with the CRA, depending on the citizenship of your customer base. Another good example is the all good ETSI 303 645, which is the first global cybersecurity standard for consumer IoT products. Creating a cybersecurity baseline for manufacturing, which has helped ensure cybersecurity for any IoT device.

(25:42):

Last but not least, another act that we have to follow now, is the Cyber Resilience Act. Still in the concept phase, beside listing what your new product has to comply with from the security point of view, one has to select the best technologies available on the market for the given product, for the given idea that you want to develop. And for that, one has to consider both physical and logical security measures, and I'll list few of them without pretending that it's comprehensive. I'll list few of them to give you an idea.

(26:31):

Let's start with the physical security measures. You may consider to have in your design tamper switches to detect when the case is opened. You may use high tamper mesh traces covering protecting sensitive areas, for example memories, so nobody can go connect directly on the pins of the memory chip. We may also think to consider hardened devices and chips with features like clock, reset, brownout tamper detection, light sensor on the die. That will all help to tell the chip that the case was breached, the case was open and has to reset itself. It has to erase itself.

(27:23):

But not least, you may consider to have part of the MCU being powered by a cell coin for an always on power. That will help to give you enough energy for just a short period to erase your memory, erase boot keys inside the wiper. Wipes everything inside the memory of that chip. So this is on the physical side. How about logical security? That is even a bit more complicated, if I may use that. And again, I will list a few of them without pretending to be 100% complete here. Again, logical security, what we have to consider there. You may consider to use MCU that has a harder "root of trust". Device has a root of trust if it starts by running code from an internal memory, which has a hard lock configuration. This represents the foundation of the security layers built on top of that.

(28:32):

If the authenticity of this early loaded software cannot be enforced, all subsequent security layers can be modified or bypassed rather easily. Staying with logical security, let's talk about firmware verification. We have to have the ability to verify the software before it executes, and stop execution if that trust is broken. Secure storage goes hand-in-hand with firmware verification. We need encrypted flash storage, encrypted DRAM even. Choose microcontrollers that encrypt the flash to increase the difficulty of extracting user secrets or credentials. The encryption key should be unique to each device so that breaking one device will not compromise the entire family of devices, the whole system.

(29:31):

Another feature that you have to consider is hardware entropy. If the embedded application requires access to a source of strong entropy, and that is used in encryptions, it is ideal to have an MCU that has a hardware random number generator. Use strong cryptographic algorithms to move, evolve microcontrollers can run cryptographic operation in hardware. That's very important. In hardware, they cannot be changed. And on top they're very fast, very efficient energy-wise. So we have a better performance and stronger security protection. Now, last but not least, here is used components that are fault injection attacks resilient. Realistically, there are very few micros and MCUs on the market today that have this feature in place. Only a few vendors take this problem seriously. We are still in the concept phase. We talked about listing all what we have to comply with. We talk about selecting technologies.

(30:48):

Meaning, the first, for example, comes an MCU. And we listed roughly from the logical security and then from physical security what that might look like. And still in this phase it's not too late that one can ask himself, or herself, can I self-assess the security needs? Can I self-address the securities on my own, or I should engage with a third party? For example, a test lab for testing, or a design firm to help us create from the get-go compliant product. That was the concept phase, followed by the requirement phase, equally important.

(31:36):

Now, what I'm going to say right now is not specific to cybersecurity, it's true for any design specs, but that much more for cybersecurity. Full specification leads to inaccurate misreading and unverifiable security requirements. More than that, all cybersecurity goals should be documented, understood, and communicated to all stakeholders. Therefore, you need a good requirement document there. These goals cover the assets themselves, their interactions in between them with the system, and any the development environment characteristics. The controls intended to mitigate risk and security requirements should result from total threat analysis and risk assessment exercises.

(32:27):

A few questions that one has to consider at this phase of requirement definitions. What data assets do I need to protect? Which vulnerabilities do I need to eliminate? What user roles are appropriate to control access, the telemetry data of performing actions? What personal information do I need to collect, and how do I intend to manage it? And then, do I intend to share any data with third parties? And if so, what data sharing agreements are necessary to be put in place? Within this requirement phase, there are few things that we perform in a form of a cookbook, if I may.

(33:20):

For example, developing a threat model. This is an abstraction of the future system. It profiles the potential attackers, including their goals and methods. And finally, the potential threat that may arise. Threat modeling should be performed early in the development cycle and requirement phases. Yes, we are still early in development cycle when potential issue can be caught early and corrected, preventing a much costlier fix down the line. Remember we said we're going to talk about recalls. Using threat modeling to think about security requirements can lead to appropriate architectural decision that help reduce threats from the start.

(34:08):

We don't have to forget about user access control requirements. We have to clearly define now at this stage entry points and interfaces for users to authenticate and get access to the device or assets. Also, we have to define how the user authenticate themselves. Are we going to use some biometric reading devices? Are we going to put on top of that two-factor authentication? We have to think about all this mechanisms from the get-go. And it is paramount we do not forget about the user privacy and data management requirements, as we touched before. European, and not only them are very big on that. Define what mechanism technology are used to store and sharing the user data with third parties and within our system. So few things to consider from the cybersecurity point here now at the requirement phase on top of everything else when it comes to defining the new product.

(35:20):

Past this moment, we'll go into the design prototyping and validation phase. On your screen, this is shown as alpha prototype phase and beta prototype phase. With that, we'd like to point out one more time that this part of the design process is an iterative part. We show only alpha and a beta prototype, but you can have more than that. And it's a short burst of effort to create a look like and function like prototype of your final product in stages, approximating more and more accurate the final product and continually testing. Continually testing for functionality, for compliance with FCC, PTCRB, and all the other standards. And now let's think about cybersecurity, we have to test against those. So we have to iterate quickly and test more, test a lot. Because if you have to fail, it's better to fail at the beginning of those phases.

(36:36):

Speaking about alpha and beta prototype, there are few considerations to think here. Hardware, obviously firmware, software. And I like to point out that due to the complex iteration of hardware and firmware in today's modern designs, opportunities arises for unintentional security flaws. That is why at every step of the design process, from block level to detailed design, one should verify security requirements to ensure compliance with clearly defined security specifications. Casual testing is no longer enough. As I said, at each and every stage after each iteration of the prototyping, you have to test totally. Each development step from block design to integration system, including hardware, firmware, software is another opportunity for a mistake that undermines security. This can lead to security surprises that can have dear consequences. And here are a few pitfalls.

(37:48):

You may use hardware components, that include embedded software that can be a source of security vulnerability. This could be as simple as exposed or unsealed hardware interfaces that leads to tampered firmware code down the line. So make sure to disable unused ports, for example, UARTs, SPIs, and disable all debug interfaces. Another pitfall is using components from many sources. Components and subsystems from third party suppliers that are incorporated into the design should have undergone their own security assessment and testing prior to integrate into a design. Therefore, one of the solutions here is to purchase components only from trusted sources, preferably buy directly from the manufacturer.

(38:52):

Last but not least, in this little series of pitfalls, be very careful with the use of open source software that is maintained by a community of developers. It's tempting to have it, it boosts your development, but it may not have serious security testing performed. Or even worse, in time there is no guarantee that you'll have security patching through this open source software. So you are going to use it, it is your responsibility to clearly vet the software, to properly test the system that use such and such a software. On top of everything, at this stage of design, you have to make sure that to perform Cyber Resilience Act assessment of the product, you have to be mindful what that is required, and we'll talk about that in next two slides. And we have to assess your development against that. You have to ensure vulnerability management process are fully implemented and they're working, and have to ensure compliance reporting process are fully implemented and working as well.

(40:24):

We are done with the design. We move now into manufacturing. And manufacturing doesn't start with a huge production usually, you go through a pilot phase. And as a different color pilot phase is in black right now because it's not developing anymore, but it's not yet manufacturing, it's both of them and in between. Yes, it's manufacturing. It's the moment when you eventually pass all the blueprints of your development, the result of your development process to manufacturing. And the manufacturer, the CM, is implementing the first production in the form of a limited series pilot phase.

(41:05):

At this moment you start to manufacture board, you have to load firmware, you have to load software, you have to test the system, and you have to package and ship them. What are things to watch for at this manufacturing stage? To ensure that security and continuously audit manufacturing procedures, at the end of the day, CM is responsible in front of you for his security and to maintain his manufacturing procedures, but you bear the responsibility in front of your customers. We have also to ensure firmware and security credential installations is tamper and privacy protected, so you have to make sure that the process of flushing the boards is as secure as possible. I mentioned that before, but I'll put it one more time here. Ensure that backdoor testing ports are closed for all embedded devices.

(42:11):

Sometime it is overlooked, but you have to secure the firmware image on the server storage to prevent leaks. Encryption of the stored images and authentication for the server access should be thoroughly implemented. And I will say again, last but not least, ensure and log the secure generation of unique crypto to keys. You have to have a clear record of what device get what key, and what date, and who was implementing and who loaded that thing. Yes, we manufacture, we have products, we put them on the market, and we go on to the next stage. Which is the product launch and sustainment phase.

(42:54):

If the previous phases were challenging, yes, everything is challenging in its own right. But the launch and sustainment phase is in fact, in my opinion, the most challenging phase. And why I'm saying that? Because of the duration of this phase. You can have a product four years on the market, and that gives many chances for an attacker to go again and again and again against your protections, against your product. And then not to mention that in time the attack methods and attack technologies evolve themselves too. What is important to have when you go for launch to make sure that you go through a successful sustainment phase? Before the product launch, it's paramount to ensure that the vulnerabilities management process are implemented.

(43:54):

It's paramount to have security monitoring responses, and recovery processes should be thoroughly designed and implemented. Security compromises to be detected, recognized, logged, timed, and acted on in a reasonable time. You have to have resources that can act against those threats. The design should include mechanisms to create and store log files for security events. All that, all this has as the bottom line, the bottom building block, the holy grail of new IoT devices. The OTA firmware updates, firmware and software updates done properly. Remote firmware and software updating can help and get you out of many troubles during the life of the product.

(44:55):

And now is the moment to talk about recalls. Imagine as a company that has a hardware product, has to recall thousands, or worse, millions of units off the market. That can be so expensive, that can ground the company, can drive the company into the ground. And as Kevin mentioned before, how about your reputation. Even if you survive that expense, how about your reputation? So think security. And security should therefore be treated as an important fundamental element of product development and should be built into the product design process for all designs, for all disciplines. Hardware, firmware, software, included even mobile app as the case may be it. It has to be done natively from the beginning of the development process.

(45:58):

And with that, let's talk about what is the best time to prepare for the CRA and make your product secure. And as always, the answer of that question, it is now. And it is as simple as 1, 2, 3. We definitely recommend to fill the NXM survey to get your security score. By doing that, it's no cost to you. You'll be able to self-assess, how do you score your product against this new standard? And you may even discover what you know and what you don't know about this new Cyber Resilience Act. Please feel free to access resources on both pages, NeuronicWorks and NXM pages. Last but not least, please call for a consultation with our specialists and engineers. We'll be very, very happy to talk with you. And with that, I believe we will take questions now. Thank you very much for your patience.

Divya Allen (47:11):

Thank you, Kevin and Titu. We'll now take some time for questions. Just a reminder to type your questions into the chat box if you haven't already. Okay. One of the questions that have come in is, what is the range of products that this CRA will apply to?

Titu Botos (47:29):

Is that for me?

Divya Allen (47:29):

Yes.

Titu Botos (47:29):

Oh, thank you. The proposed regulation will apply to all products with digital elements. That includes logical and physical data connections to a device or network. And it applies to direct and indirect connections. Okay, let me translate that in more common words. Any device that has a connection, wireless or not, any IoT device has to comply with this standard if it has to be sold or used by citizens of EU. And I do not recall in the last 4, 5, 6 years design any new product that doesn't have an antenna, a communication within.

Divya Allen (48:28):

Okay, thank you, Titu. The next question, what does conformity assessment mean?

Kevin Oerton (48:36):

Okay, I can take that one. Yeah. For the majority of products, this can be a self-assessment performed by the manufacturer. Importantly, the manufacturer is still liable for any misrepresentation in their self-assessment, but they also go on to identify a separate set of categories of products where a third party assessment may be called for. And what they're really getting at here is, they've highlighted certain critical industries, critical national infrastructures. Which if they were harmed through security events, it would have major consequences to that country's economy or society. And so this is just a small sampling of the types of products which would be elevated in terms of requiring, again, a potential third party assessment. So robot sensors or actuator components, robot controllers, smart meters, industrial IoT, industrial automation and control systems, programmable logic controllers, distributed control systems, computer IC&C systems, SCADA systems, et cetera. So you can see there's a real focus here on those classes of products that are used in things like electrical grids or manufacturing environments. Maybe just the fundamental services that if they went down it would cause major disruption.

Divya Allen (50:21):

Okay. Thank you, Kevin. Another question for you, I guess. Can you help meet IEC 62443 cybersecurity standards?

Kevin Oerton (50:35):

Yeah. Well, that actually relates to the last question. This 62443 is for industrial IoT. And specifically, industrial automation and control systems. And so what I can say is that NXM's platform is aligned with something called SESIP security evaluation methodology for IoT, which is a device security certification ecosystem. And so SESIP provides a common and optimized approach for evaluating the security of connected products that meets the specific compliance, security, privacy, and scalability challenges for the IoT ecosystem. The nice thing about aligning our platform with SESIP, is that SESIP itself has taken very strong efforts to harmonize the set of security requirements that your product, by passing CSIP, can then also get you quite a ways towards achieving compliance with other certifications. So in other words, CSIP is harmonized with other certifications, and therefore provides a fast track to achieving certification on these other standards. Including IEC 62443. And by the way, ENISA, which I had mentioned earlier as the EU Agency for cybersecurity, they are also actively participating in the SESIP ecosystem.

Divya Allen (52:21):

Okay. The next question, if I don't manufacture my product in the EU, do I have to worry about Cyber Resilience Act?

Titu Botos (52:35):

Yeah, thank you. Titu here. The regulations apply as soon as you supply a networkable product for distribution to use in the EU. It doesn't matter that you are paid for that or it's a free use of charge. The moment you supply that in EU, that connected device has to comply with the new CRA.

Divya Allen (53:01):

Okay. Does this regulation apply to products that are already in the market when the rules come into effect?

Kevin Oerton (53:13):

Yeah, I can take that one. To allow manufacturers to basically adapt and have time to adapt to the new regulations, as soon as this comes into law, then basically that's when manufacturers, the timer starts. Manufacturers basically have 24 months to ensure that all of the products that are still on market are revised to support the security capabilities in order to continue selling that product, all of that action needs to take place before that 24 month period expires. But then there's this other reporting obligation, which means that for your products which don't yet come into compliance with CRA, you will nevertheless one year from this law being enacted, have to provide a list of what all of the security deficiencies are with that product. In other words, there's a real incentive, as Titu said, to kick off your internal strategy to see what makes sense, given the constraints that you're facing within your organizations. But clearly there's increasing requirements. And so, this stuff takes time to adapt to.

Divya Allen (55:06):

Okay. Thank you, Kevin. I believe we have time for one more question. What is zero touch and zero trust security?

Kevin Oerton (55:23):

Zero trust means that no endpoint or user is trusted within a network, and it must individually be authenticated, authorized, and continuously validated for security configuration posture before being granted access to the network or the data. And then NXM takes this a step further by taking advantage of next generation capabilities, such as Titu was talking about, some of the upcoming processors from various chip manufacturers that incorporate things like Arm TrustZone capability to eliminate a new generation of threats, including ransomware and insider threats. Zero touch, on the other hand, focuses on passwordless security and automation to secure endpoints and access to data. In other words, making it easier from a user experience perspective and from an administration perspective to allow devices to carry out their security requirements. So taken together, they both form what we call autonomous security where endpoints can autonomously protect themselves and monitor for security events to enable recovery from cyber attacks.

Divya Allen (57:00):

Okay. One last question maybe. We have a couple of minutes. Do you expect other countries or regions to adopt a similar act?

Kevin Oerton (57:12):

Yeah, I can take that one. I think we're seeing that the EU is leading in this area, but that other countries are also following suit. For example, in the US there's Executive Orders that are looking to achieve some of the same ends. And so NXM is looking at this as becoming a global requirement. I think much like California is the marketplace for environmental laws and regulations, so companies that pass and satisfy California basically have something that they can probably sell anywhere in the world. Similarly, by designing for the strict EU requirements, the principles that they are requiring are universal. I think any other country would be following and implementing and requiring regulations of a very similar nature.

Divya Allen (58:19):

Okay. Thank you, Kevin. We have a question asking if this is being recorded and if we can send the recording out after the presentation. Yes, this presentation is being recorded and there will be a link available on our website, which we will share to all the attendees post this event. Thank you for that.

(58:40):

We've had some amazing questions so far and unfortunately we have to end the session now because of paucity of time. If you have any questions that were not answered, or questions that come to mind after the session, please feel free to reach out to Kevin or Titu at their contacts listed on the slide. Thank you once again to everyone at NXM Labs and NeuronicWorks helped put the session together. Thank you for joining us today and we hope to see you next time. Have a good day.