Precision Over Panic: How to Focus on Real Risk for CRA Compliance

appreciate the introduction. Maybe just to give everybody a quick introduction on myself, As Nicole mentioned, Dario Lobozzo. I've been in the cybersecurity world for my entire career, and I have been in the product security world for coming on around three years now. It's an interesting move over. I come out of the critical national infrastructure and OT security side of the house. So not dissimilar. Definitely operating in regulatory environments for quite some time as well. That brings some specific challenges to organizations that I think we're gonna talk a little bit about today. So today's focus is on CRA. Although looking at the preregistration list, it's obvious that we have some people here from many different walks of different verticals. So we'll kinda we're going to cover kind of a more of a broad to pinpointed approach. So that's the idea here is to go from high level to low level. Maybe before we get started, I wanna just maybe throw a challenge out to you. We do have the q and a, as Nicole mentioned. Take a moment now while I'm talking and doing an intro to go and find it and open it up. I do ask that you ask some questions. This is for you, so feel free to get engaged. I know some of you are on with Teams, and you might be talking with each other. Even if you come up with one question amongst your team, you'll be doing better than those who ask no questions. So please do ask some questions. So I'm going to get started here. So for the session today, we have an agenda of essentially several different points that we wanna make sure everyone walks away with. Going to set the stage for what CRA compliance is asking of organizations. Then we're going to look at the current risk landscape, and walk through a bit of a the problem statement. Then we'll get into some of the complexities that come with what is being asked of you, and how to maybe start unifying some of those complexities. That's kind of a goal of the entire presentation. And then we'll come up with some strategic recommendations, and we will definitely be leaving time for q and a. So please make sure, again, that you ask questions. Coming out of the session, we're gonna really focus on, bringing value directly to you. So we are all running in the exact same economy. So avoiding any time you could do, overwork or duplicative effort is extremely important to organizations. So we're going to focus on how you can accomplish that. That can only be accomplished when you can map your risks contextually so you can actually get, from that high level to that low level connectivity between your your various organizational points of requirements and the vulnerabilities that hold those risks. We'll also talk some technical bits as well about how you can start with a binary, maybe a product, and enrich that information into something that can be used for exploitability and reachability analysis. And then we're going to look at making sure that you can align your remediation across your product security and compliance teams. Because at the end of the day, an organization is really just people, process, and technology coming together for a unified goal. So let's get started by maybe talking a little bit about the current digital landscape. This problem statement here essentially outlines the fact that, at the compliance level, at the big picture level, organizations are being asked up here to achieve a certain standard or to achieve a certain idea of what will make this entire world a safer place. I look at compliance and regulate regulations as kind of an artificial adversary. It's someone who's supposed to guide you towards a more secure outcome. The unfortunate reality of that, though, is it doesn't take into account the fact that your day to day risks and quantifications and mitigations don't sit at that top level in the theoretical world. They sit at the bottom level. In in this case, since we're talking specifically about software, they sit within the individual releases and products and code that's being distributed to the world. That means that as an organization, you are currently being faced with a very specific problem, which is how do I contextualize these very specific vulnerabilities, risks, attack vectors to this very kind of higher level arbitrary compliance outcome and goal. There are several different ways to do that. Many different people have accomplished it. There's checkbox exercises. I don't believe that CRA will essentially allow you to, accomplish that. But at the end of the day, you are not just likely going to be, beholden to CRA. You're likely going to be, held to several different standards. So if you're here from the automotive sector, you might have a port part of your portfolio that is CRA impacted, but you also have a more stringent regulation with two one four three four and r one five five. If you're here in the, from the the the UK side of the organization, then you might have PSTI on your mind. If you're here, from the the US arm of an automotive organization, maybe the connected vehicle rule is something that's keeping you up at night, Or you put cars on the road in China, and the g b four four four nine five is keeping you up at night. The goal here, though, is that if you have a foundational level of an approach that is scalable and extensible, then you're setting yourself up for success as this regulatory landscape proceeds. What we're seeing, though, is that many people are kind of entering what is kind of the obvious risk assessment approach. People are moving towards doing one or the other or both and then trying to do some kind of long winded integration. So when you start looking at any kind of compliance standard, the first step is typically to do some kind of controls only approach. So this is looking at contextualizing your risks exclusively through the lens of security controls. So this includes typically interviews and paperwork review, maybe some kind of gap analysis to understand which products are beholden to which regulations, by what timelines, what teams are responsible for those products. We've all been through these types of kind of granular controls assessments, and the technical depth that is kind of needed to contextualize those risks in the real world is something that usually has to get handed over to another team. That is block number one to you being successful. The alternative is I'm a member of a product security team or maybe just a development team that's bringing a new, I don't know, pump to the market for a medical device in this. And this pump needs to reach the market by q two of twenty twenty six. And I have a certain budget that I have to get it done in. That's our entire r and d budget, and that includes everything from, the plastic clips that are gonna together to the software that is actually designed to keep this thing operating, and that has to be in a secure way. So part of my budget is going to go towards security gap assessments through, essentially, technology. So we'll run some kind of scan. We'll assess the scan, identify if the scan produces any vulnerabilities, maybe send that to my SOC analysts. And then, really, it's quite difficult for this purely software focused approach to actually make any kind of headwinds in the connectivity of the overarching compliance challenge. So let's stop here for just a moment and reflect on the integration challenge. The fundamental challenge lies in the fact that many people are showing up every day. They're doing the very best they can at their jobs. And at the end of that day, they're not figuring out how their job can overlap with somebody else's job. It's a silo problem. It's not uncommon. And, frankly, it's not something that you typically see people even trying to solve. So something like the controls only approach might be something you would hire one of the big four or your local consulting firm to come in and do. And while the software centric approach might be something you go and buy a tool, you get it done for the six month release schedule of that project, and then you have to do all of that over again because it all is essentially out of date once you've moved on to the next product. I don't believe that that necessarily has to be the way we go forward. I'll touch on that in the next, in a few slides, but there is some serious costs to doing this fragmented approach. Your resources are highly inefficient when you do it like this. We are estimating that there's about three hundred days that are lost to this assessment time. The typical way to achieve these types of assessments is to go through the full controls assessment. Then once you're through the controls assessment, hire some, people in your organization to bridge those gaps. And, ultimately, those people get overburdened, and they are not able to do kind of the full overarching assessment to product mapping. And you end up with either delayed projects or you end up with canceled projects or indefinitely suspended projects. All of these issues can compound over time, especially as regulations continue to expand. And conversely, if you were to invest in a scalable approach and build a program that is strategic in nature, then that same compounding can be applied to that likely existing backlog inside of your organization. So in order to kind of understand what the the efforts can entail, you know, this is something that really gets intensified as an organization. So, you know, we've seen some smaller orgs actually very successfully do kind of the bottom up approach where you look at your third party library vulnerabilities. You look at your supply chain dependencies. You can map them pretty easily. Maybe you only have fifteen developers and two products on the market, and then you can kind of use the outcomes of that to figure out who you have to satisfy at the auditor level. Where it doesn't work, though, is when you have a bigger team because, ultimately, what ends up happening is your fragmentation creates this complexity, and this gap of kind of going from the bottom up or the top down gets intensified as you start to have difficulty prioritizing which remediations are high risk, which remediations are high compliance risk, which may be different than human safety risk, which remediations are actually, if I apply it once, are going to have a broad level applicability. How do those decisions and inefficiencies in those decisions impact the allocation of my security resources? Am I going to actually have enough security resources to accomplish all the various goals that I have set out for myself? All of these challenges are kind of inherent in this approach that is quite typical. So, ultimately, what ends up happening is you you kinda go through a controls assessment. And I maybe wanna pause here just to add, I will not be recommending that you don't do any of this. You need to do all of this. It actually must occur that you look at what the compliance is asking you to do. You look at what you're developing, and you bridge that gap. It's not an option not to bridge those gaps. But the way you typically do it is you go through a full controls assessment. Following that full controls assessment, you end up with this very long tail of remediation projects. Those disconnected remediation projects start kind of trickling into your security teams, your product teams. Those teams start to identify which things can I start fixing, which things do I have to give up on, and find another way to accomplish it? You're already now behind the compliance deadlines because everything I just described can only happen in serial. Right? One thing has to happen. Then once you finish it, then you can start the next thing. Then you can start the next thing. This is slow. This is not going to get you over the line, and it's not going to do so in a way that is repeatable. And then lastly, you end up with, essentially results that live in a void. They maybe get produced from, the security team, and then they end up on some kind of report. And then that report then needs to be interpreted by some middle party to meet that compliance burden for for your endpoint certification. I don't think that this necessarily needs to be the way that you proceed in the future, but this is the reality of what it looks like today. I propose there is a better way. There is what we are calling a unified risk assessment. This is what we call innovation through unification. If you give me a moment, just gonna so the finite state approach is what we call a velocity match methodology. What we are doing is we've revolutionized enterprise risk assessments by employing a parallel controls evaluation alongside a comprehensive technology assessment, all in unified platform. So what does that mean in practice? What that means is that your product security decisions and results will live in a unified platform. So somebody from your SOC team is able to look at the data from their perspective. Somebody from your reports team is able to use an API to pull the data out into the perspective that they care about. Somebody from your development team is able to use this as part of their CICD pipeline to automatically identify which things matter and which things don't. And all of that gets mapped alongside of our strategic consulting team. Our strategic consulting team has a people process and controls assessment, approach that is a technical partnership with your organization. These kick off at the exact same time. You scan binary number one at the same time that we are doing interview number one. From the outside in, we're also able to do a market access gap analysis. We've done some very interesting financial and economic analyses on the market right now. At this moment, I would like to add security is not what's driving spending in this arena. I need to make sure that I do not lose market access is what's driving spending in this arena. So there are several regulations. CRA is not necessarily one of them. Although they have a fine associated with it, they do not bar you from accessing the market. As I mentioned, many of you are on this call from multiple different markets. If you look at the FDA, on the other hand, you just can't go and recover your r and d dollars until you've achieved that particular compliance burden. Similarly, for several of the automotive regulations and similarly for, several consumer electronic regulations as well, such as the CE red, which is, again, a required state a required declaration of conformance in order to actually reach market access. Then from the inside out, we're able to do strategic consulting within regulatory environments. We have a very, very strong credentialized team that is quite capable of working directly with on the ground regulators. Think people inside of the governments that you operate within to prove to them the level of burden that you'll need to make to show them that the technology that you're working with is not going to add risk to that organization. I use that as a very high impact example. That same type of example from inside out might just be to a regular old auditor who's local in your country. Doesn't necessarily need to be a government body. But just to give you an idea of the type of work that our assessment team is doing. So the way that this looks in practice, I think, is really the best way to kind of understand what what this is going to accomplish for you. We're essentially going from unified discovery. So we're doing software analysis alongside of controls gaps analysis. We're scanning, and we're doing assessment at the same time. We're correlating the results of the technology with the results of the gap assessment directly. So that's done in mostly automated way, but you do still need some people to stitch those two things together. This brings me to another global challenge, which is we have a major shortage of qualified individuals to do this type of work. We are blessed on our team to actually have quite a large, grouping of those people, which we can lend to you for your efforts. We then take prioritized actions. We take actions that align directly with not only business impact, but also compliance requirements. Taking those prioritizations is the difference between overreporting or overworking and not doing that. This is really where you're starting to take, euros spent and correlate them with euros saved, which I think is a extremely important component of what we should be doing when we're building the business case for why we should be doing it this way. And then all of that goes from the outs from the inside out to have a direct connection between your technical findings and your regulatory framework requirements so you have a streamlined audit preparation. Why is that important? Again, back to nonduplication of effort, which is this is where you're going to see that if you've chosen six two four four three as your internal methodology for producing secure environments, that likely has eighty five percent overlap with and don't quote me on this. I'll put you in touch with Larry who's on our services team and tell you the actual percentage overlap. But there's high, high correlation between doing it right once and then reporting on it in several different flavors to satisfy multiple different orders, compliance regimes, governance regimes, local approaches. We deal with many different companies that have centralized group level organizational directives, but maybe they're a member of ten, fifteen, thirty companies that are all part of the group of organizations, each operating independently. You might have a similar fractionalization within your org. Maybe it doesn't maybe it's not called business units. Maybe it's called operating companies. Maybe it's just called divisions or franchises. The concept remains the same. Give them the tools necessary to do this discovery, correlation, prioritization, and ultimate alignment, and they will do it. If you give them just the last part, you must get aligned as a directive, that produces this fog where you end up back to, slide three, and you start having to force people to figure out how to get this done. I'm gonna pause here for one second. The next thing we're gonna jump into is an actual real world case study. And if you haven't submitted a question by now, we are around halfway through the content section, and we'll have some q and a a little later. This is your moment to think about everything I've said and come up with something that you'd like to learn a little bit more about and submit a question. So let's take this momentum that I've been talking about and move it into practice. So one of the key components of saving your team's time is reachability. Why am I talking about reachability? I could be talking about SBOMs. I could be talking about CWEs, faxes, EPSS, lots of different things we could be talking about. But, ultimately, most of that is really just additional data points. At the end of it, you need a so what moment. So what? I have all this info. So what? Without that, you're never gonna move past analysis. So I want you to have that in your brain when you're thinking about why should I be talking to organizations that can help me get to that next step. Because the next step is making decisions and actually coming up with solutions as opposed to continuing to analyze and finding yourself in analysis paralysis. So from our perspective, what you're looking at here is step one, a binary gets imported. Step two is to identify, is this binary singular, or is this one of five, ten, fifty that constitute a product or a project? You think of your average vehicle, you might have somewhere between fifty and a hundred and fifty ECUs or computers, ADAS, or or infotainment systems within that that device. MRIs, you might have fifteen to thirty different components, each having their own little piece of software, printing machines, food processing machines, satellites, you name it, PLCs, wind turbines. All of these components have some number of different pieces of software that need to operate together. When you look at the CRA regulations, they are not asking you for a report against a binary. They're asking you for a report against the product, the thing that you sell from your business to another business or to the consumer. So contextualizing risk doesn't actually stop at the I scanned the binary. I found a vulnerability. I don't have to worry about it. I don't have to report it. It goes to the overall product level. So if your team is responsible for the temperature control in this product, but there's a whole other team that's responsible for the actuals the actuation actuation of this robot, then you need to collaborate with each other, or you don't need to collaborate with each other. And maybe there's a product security team that sits above you and helps you identify which components map to which exploit exploits, and lastly, which things are reachable. So what are you looking at here? In the small picture on the left, you're looking at an overall project. That project has had several different binaries scanned that all constitute this one particular project. That project consists of twenty nine thousand four hundred and forty seven vulnerabilities. Sounds pretty bad. Those vulnerabilities exist inside of five thousand eight hundred and ninety seven components across all the various projects in that binary or binaries within that project. Sorry. What does that mean? Both of those are really just getting us to the the SBOM and the enrichment state. Now we're starting to move into analysis because below that, you can see we have high, medium, low criticality, and EPSS ratings. Good. Now we're starting to move into data that we can use to make a decision, but we're still missing that last step. I doubt that there's anyone on this call that has fifty eight hundred developers. So we're gonna have a hard time handling this number of specific components and vulnerabilities associated with it, let alone thirty thousand. So the last step is to be able to actually filter by reachability. That reachability is going to bring it down fifty one things you need to actually worry about. What are these fifty one specific decision points you now need to go action on? Essentially, our reachability engine is able to help teams detect and prioritize their vulnerabilities by looking at the actual code execution paths within there. So we're taking each vulnerability. We're comparing that vulnerabilities, exploitability rating, and the means by which you can exploit it. We're using that information against what we've identified in the enriched SBOM to identify, is this particular exploitable code snippet attack vector, whatever is related to that vulnerability, is that something that this particular this particular implementation of code would allow an attacker to actually leverage to move to the next step? Why is that related to CRA? Am I just making a sales pitch here? No. The reason why that's important for CRA is because you are only required to report things that are both existing vulnerabilities and exploitable. K? Doesn't talk about reachable, but you need to be thinking about reachable. Because in the event that that particular vulnerability is not reachable, the next thing you have to do is write a disposition documentation indicating why are these six hundred and forty one unreachable findings, in fact, not reachable. And that's where you can take it to the next step and actually identify specifically this vulnerable kernel module was not found in the SBOM. In addition, we tried to attack it in this other meet this other from this other vector. We also tried to attack it in this other vector. We did the following various technical audit trail to show you as an auditor, to show you as a my declaration of conformance that this particular vulnerability, despite existing, is not reachable. Being able to automatically write that disposition and that type type of reporting granularity is going to save six hundred and forty one reports worth of time and effort in your organization, not to mention the actual technical feasibility it takes to actually go and determine that this finding is unreachable. Let's pause there. You've saved a ton of money because you don't have to go now. Pay people to go and do this arduous, monotonous work. Now we get to the fun part, fifty one that matter. Taking that extra step to identify that this particular vulnerability is indeed reachable, is indeed something that you need to worry about, this vulnerable kernel module, CFG eighty two eleven, is present, and this is exactly where it exists inside of your kernel. I don't see any other compensating controls within your software, so you can hand this directly back to whatever size development team you actually do have. And now they can start directly resolving that. And I can't help you there. That's on your development team's part. But I've already helped you go from twenty nine thousand to fifty one things that your that your team actually needs to go handle. This is where you're starting to make a huge difference in actually producing audit ready reporting that has real documentation with attack path evidence that's directly helpful to both your developers and your authors. Now you're bringing direct value to your compliance team and to your development team. You're bridging that gap that I talked about earlier in the presentation. Aligning those two remediation paths is quite a lot harder than it This is one capability set that I wanted to focus on as a a an actionable example. There are other ones that we don't have time to go into here, but this is one example of being able to take a high level outcome and map it directly to a very, very specific kernel module. I want you to ask yourself, how would I do that today? Lastly, this goes alongside this is the technical side. This goes alongside what would be an actual consulting engagement, essentially. So here is a an example timeline that lines up with the previous technical example. In this particular client, this real world client, we took q four to do, essentially, a we deployed the platform. You saw that in the last slide. We did some stakeholder engagements. We started to identify and prioritize which operating companies and which products have compliance requirements. Also, what timing we should be concerned about for those compliance requirements. In this case, we have EU red, which is overdue. In fact, they actually already need to handle this. This is a good opportunity for me to talk about some of our partnerships. We have a partnership with a company called Quectel that is capable of doing that does essentially wireless modules. EU red is one of their strong components there. And we are seeing people come to us and say, I kind of understand how to get on Verizon's network. I understand how to maybe manage the FCC in the States and the European division of of wireless equipment, but I don't understand how to do this cybersecurity burn. Let us help there. In q one, we move into the first ten operating companies' gap assessments, and we're specifically doing remediation road maps so they can directly start taking those automated discoveries of the software assets and the security controls and start solving them directly and immediately. And then only in kind of later in the year have we kind of prioritized finishing up the deployment of the platform. Because, frankly, we already did an assessment during this year to identify that there were some higher priority components that we needed to accomplish to overcome the regulatory burden. So by taking this parallel path, we've essentially accomplished quite a lot more in quite a shorter amount of time, which ultimately is going to save them a fair amount of internal resources and directly going to save them a fair amount of money. Speaking of money, we have a specific outline for what this combined solution framework costs and comes together as. Essentially, it's typically something you want to do over a certain amount of time. These regulations are, evolving, and you likely have, more than one year's worth of work to do. So we typically try to do this over a multiyear period. This aligns typically with your, with your organizational goals directly. We look at this as a technical partnership. That, platform typically comes with a consultancy engagement, which has some planning and scoping, which we agree on, then we iterate through to a gap assessment to an implementation and compliance approach, and then we continue to ongoing monitoring with with the the product and ongoing vulnerability disclosure with the organization. Why is that important? There is almost no regulation on the market today that is only a point in time effort. Most of them, including CRA, including two one four three four, including FDA, including MDR, are all requiring you to do continuous monitoring and vulnerability disclosures on a regular basis. That can't be done for free. You have to put time and effort and correlation. All that gap project process I described earlier needs to occur regularly. And so that's something that we can build in here. You'll notice that the numbers are blurred out here. This is something we'd be happy to share with you in a one on one session. So I would ask that you receive your follow-up meeting here, or if you wanna just drop a note in the q and a that you'd like us to reach out, then we're happy to happy to set up a session and just kinda walk you through what this might look like in practice. I want to redouble the ask for questions because we're coming up on forty minutes right now. So we're gonna start kind of moving into the conclusion section here. Coming out of this, it's important to to look at a comparison of traditional approach versus what we're gonna call the finite state velocity matched approach. In your traditional approach, you're looking at around three to six months to first do the comprehensive assessment. Only then can you start doing remediation planning and actually start working its way into connecting those findings? With our approach, we're looking at day one, integrated vulnerability and controls visibility. That outside in approach, looking at which products are in in scope, will dictate which products you should be scanning first, which products you should be enriching first, which products you should be mapping risks contextually first too. So day one versus three to six months later. In your remediation planning, again, we're looking at doing manual correlation, which can only happen sequentially with the traditional approach versus an automated mapping to specific software components. And some point next year, we'll be having a very strong compliance module, which will look specifically at which software components are applicable to which compliance outcomes. Taking all that together, your regulatory framework alignment is something that, frankly, could easily take a year if you do it in the traditional manner. We don't have that time here, listed on the slide, but I can tell you that I am engaged right now for over eighteen months with two clients that have been trying to do this, and they've called us in to please help them move from the trying to the doing phase. These multiple disconnected teams and tools are again exacerbated by the traditional approach because people change over the course of eighteen months in your organization, and that requires retraining and without a unified platform to centralize all of the various intelligence bits you get out of all of the efforts proceeding, then you essentially need to do continuous iterative work, reeducating new people on these peer periodic reassessments as well as these, touch points within your compliance process. So I wanna lastly touch on the continuous monitoring, which is something that is automated and built directly into the platform. That automated assessment, correlation, and production of a vulnerability disclosure, that whole process I just described, that is what is required of you for CRA. So how do you accomplish that without some kind of tooling to help you do it? And the short answer is you have to hire people to do it, and you have to do it, require a significant amount of upfront investment, which is ultimately going to give you, a delayed outcome. I believe that this unified approach is quite a bit more effective. It is not rocket science. It's really just a matter of finding, technical partners that are game to try this other approach and to be willing to really put your efforts where they're going to matter as opposed to, maybe what seems like a traditional good idea. So I think that these there's ways to kind of do the same thing but accomplish it in a more streamlined and efficacious manner. So in closing, we recommend that executives, directors, managers, operators, developers, everybody across the chain be advocating for essentially three of the same things. We do not want to do things in silos any longer. We need to adopt an integrated assessment framework. Integrated means that we're going to move from silos of people and and data that do not connect with each other and move towards an evaluation process that feeds into a unified platform so that multiple different stakeholders can gather the important information for themselves at a regular at regular intervals and without needing to necessarily synchronously convert that information. That is going to allow you to prioritize the velocity that's necessary to stay ahead of both your development and release schedule, but also stay ahead of the compliance burden that is already in front of you and potentially backlog as of today. And all of that is essentially not helpful if you just do it and talk about it. You need to trace it. You need to track it. You need to actually provide clear connections between your identified risks and your specific software components. So at the very, very top level, risks and compliance outcomes. At the low level, specific product components and vulnerabilities. And who is doing that work needs to be fully auditable so you can actually identify. So and so did the following disposition, and I have the documentation to support it. And that's one mundane example of regulatory reporting that's going to take you from the traditional obvious approach to the velocity matched approach, which is going to move you towards a much more secure cybersecurity posture. With that, I'd like to maybe open it up for q and a and see if we have anyone who has anything on their mind they would like to share. Alright. Thank you so much, Daria. We do have a couple of questions here. The first one, who typically owns the CRA compliance process? Is it security, engineering, legal? It was about two years ago that I moved from having meetings exclusively with the development teams to asking myself, why is there someone here from legal? All of a sudden, you started to see people who really knew nothing about the demo you were showing them trying to understand how that was going to relate to the big stack of paperwork in front of them. I wish I had an easy answer for that question, but the short answer is this is one hundred percent a team effort. So the CISO is likely going to appoint a chief product security officer. That product security officer is going to then appoint some deputies inside of the organization that's actually developing code to actually produce secure code, or maybe it's a directive that goes across the organization. And all of that needs to be correlated up to legal. So the the trick question answer is everyone. Alright. Thank you for that. I have the next question here for you. Doing the required risk analysis for a PWDE can lead to a long and complex document. How can the risk analysis for EUCRA be simplified? What is the appropriate granularity? I think that that's a really tricky question. There are kinda low level requirements that the CRA is asking you for. Just filling those in is something that our team can kind of help you check the box for and have defensible actions for. So doing it in a way that's actually, you know, the the minimum effort and then waiting for a response and then ask and filling in kind of what you get as the next response, that's that's one way to simplify it. The other way to simplify it is to look at, like for like. So in the case of a product that you are, bringing to us that you need some help with, it's possible that your organization has never done a certification for that type of product. But it's likely that our team has done a certification for that type of product. So just leveraging the existing know how and porting that over to your applicability, it doesn't necessarily simplify it, but it might greatly expedite what actually needs to occur. Alright. Great. Thank you. And last last question, I think, here. We still have a minute if anyone else wants to submit, but we'll we'll call this the last one if we don't get any more. Where should if we're early in our CRA compliance journey, where where should we start, or where do you recommend kind of the first steps to take? A hundred percent a gap analysis. You you need to identify specifically what products, what exposure do you have on the market, where should I be putting my efforts, and who in the organization is going to own this from a effort perspective. Like I said, it's ultimately going to need to be a team effort, but somebody should wear the hat and say, I'm gonna go bring this team together. So so so point one is appoint somebody to be the leader for your effort. Then step two is to have that person do a gap analysis. And, you know, I I hate to give up some of our own business, but the reality is is you can use a fair amount of the AI tools that are on the market right now to do some of the work of identifying which of the products that I produce, public information, are applicable to which standards. And then bridging the gap to actually get that done, still you still might need some help. We're happy to help. But I would say those would be your two first steps. Great. Thank you so much. Well, with that, I think we will wrap up here. And I think on the on the next slide here, we've got some contact information. If you would like to reach Dario or the Finite State team or visit our site. There are links here. As a reminder, we will send out this full recording and the slides to everyone who registered. Please feel free to share those with your team if that is helpful. And, you know, connect with us, we'd be happy to continue the conversation. I know Dario offered an individual one on one kind of analysis and plan, so we would be happy to to partner with you on that. And with that, thank you so much, Dario. It was a really great presentation. Thank you, everyone, for joining us. We were are so glad you are here with us, and I hope you have a wonderful day.