What I will share with you today is the impact of the Cyber Resilience Act and the Network Security Information Directive, I4C, on the identity architecture in the industry 4.0, and particularly in relationship with the forensic activities after an incident. Most of the time when we discuss this topic in the industry, the question that comes in the forensic is, who accesses what? NIS2 and CRA change slightly the equation and bring on the table a far different question, an almost complex question than that. What they ask exactly is, what remains after the facts to reconstruct that happened?
And what does it mean? It means that they would like to understand who acted, what system acted, what was trusted, and what can be still a problem. And most identity architecture are not really designed to answer that question directly. What I want to leave you after this presentation are three things.
First, industry 4.0 needs identity architecture design on four different identity planes. And I will come back to that later. And the Cyber Resilience Act makes product lifecycle identity part of company's identity architecture. And finally, the NIS2 makes evidence part of the identity architecture design. And to go there, I will start with focusing a little bit on the regulation themselves. And I will not go extensively on that. I will more talk about the impact on the architecture.
So first, NIS2 raised the expectations on the companies operating in critical sectors. They raised expectation on risk management. They raised the expectation on incident reporting. They raised expectation on supply chain management. CRA is slightly different. The CRA put the responsibility on the product manufacturer. The connected product must be shipped to be secure with security by default. And the security should be maintained along the support period. So one regulation will shape the way the company operates.
And the other regulation reshapes what is legitimate to expect from connected product. And now, if you look at both at the same time, and you see them through the lens of the identity architecture and what should be expected, you can see that only providing access and only seeing the identity through granting and revoking access doesn't fit the equation. What they expect there is that the identity must support the operations, the product, and bring evidence. And that's slightly different than what is expected.
And to do so, that reshapes at the same time the way we see identity in the operation and the way we see identity in the product themselves. And so that's the shift that will force the identity architecture to become something else. According to me, the identity architecture needs four different panels. The first one is the workforce. I would say that's the legacy one. Everybody knows about that. We talked about that for years. And it's a mature part of the equation. We know how to identify or to authenticate employees. We know how to identify and track them to onboard them and offboard them.
The third party, the same thing. We know how to deal with partners. We know how to deal with contractors. And that's the second pillar of the human part. That's the same thing. But the fourth thing is the machine identity. So more and more, we do have gateways. We do have the controllers. We do have all the names you can imagine that are taking decisions on the product line. And that affects the safety and the trust of the production. And that's the third pillar that needs to be covered on the third plane. And finally, CRA put in the equation the fourth one, that is the product.
Because product instance across the deployment, update, support and requirements must be identified as a fully part of the factory and a fully part of the production system. But why this four plane and not a single big one? Because in case of forensic, in case of incident, they are in charge of answering four different questions. The first one, workforce, is in charge of answering who acted. That is a physical person internally who acted and who take decision ultimately. The second one is in charge of almost the same decision, but slightly different.
What human from the external, from out of the factory, take decision. The third one, we answer the third different question, it is what system acted. The last one is equally important because it will have to answer a different question that is, again, what instance of the product was trusted in the incident and at what time the incident happened and what was the status of the product at that time. So I will spend a little bit more time on the last two ones because these are the most affected by NIS2 and the CRA. So the first thing is the machine planes.
So a factory runs today on machine acting without any human session. Every one of them is taking decision on, as I said, production, safety and trust. But to fulfill the regulation, the machine identity plane has to answer four questions. In case of incident, the first one will be, how was the identity of the machine issued? Who signed on that machine and who authorized it to be onboarded in the factory? The second one is, how is the trust anchored in that machine? How did we make from a regular machine, we receive a machine that belongs to our factory? How that trust was anchored?
Is it certificate? Is it hard-routed? Is it somewhere in the vendor cloud? Is it an Excel sheet sitting somewhere? We don't know. The third question that will have to be considered in case of forensic and incident analysis will be, how is that identity of that machine rotated and replaced? What process do we have in place to rotate that machine? Because credential expire, key leaks, you need to have that process in place. And how does it work exactly? And the fourth one is, what happens when that machine should be updated, swapped or retired?
Because we have to know if the identity of this machine will simply fade, simply stay there, be trusted, but without any proper retirement or will this machine be cleanly erased, if I may say, from the identity plane of the factory? And it's only with being clear on those four topics, on those four points, that we can make the machine identity plane part of the factory infrastructure, just like the network could be or the power could be. The second point I would like to make is the management of the product identity plane. So more and more factories 4.0 have many connected products.
And connected products under the CRA has to be trustworthy along their entire lifecycle. What does that mean? That means that when you deploy in your factory a new connected gateway, first you need to acknowledge that it was shipped with security by default, there is an add-on configuration, it's ready to deploy. The second point is when you operate it, something that you need to acknowledge and be able to demonstrate later will be how the access control is managed. How do I grant access to that product?
How do I control that the product has the access it needs per its definition of action into the field? The third one is how this product is updated. Not only how do I put an update, but what is the trusted path to update this product from the person who signed the update, to the person who acknowledged that the update was properly done, up to the person who delivered the update. The third point is the maintenance part of the connected product.
This product must come with a support period per the CRA, and this support period means that somewhere there is a clock ticking and this clock is auditable. I must be able to prove that at some point this product was under maintenance and the maintenance was properly done. The fourth point is, enforced by the CRA again, there should be a response plan to a vulnerability assessment. There should be a path to a vulnerability disclosure, there should be a path to the patching process and the acknowledgement of the vulnerability fix. And finally, there should be a retirement.
There should be a retirement process as for the machine, we should have a way to define that a product is properly retired and not sitting somewhere with its identity still alive. It's only with addressing all these six steps of the product lifecycle in a coherent manner to a proper product identity plan that we can answer the question that is important in case of forensic, in case of incident analysis that is written on this slide, and it is can this product instance be trusted, updated, supported and evidenced over time, because this is what we want to prove in case of incident.
So, beyond these two identity plans that should be shaped properly to answer the requirement put by those regulations that I remind you for the CRA enter into effect on September 11, 2026, and require fully compliant by December 2027, so it's in four months. It's not in four years, it's in four months.
So, beyond the fact that there should be a proper identity plan to cover those topics, the shift also the regulation bring in the way we do manage identities in those uses is the evidence that should be put on the table, and this is where NISTO comes into the equation and changes the conversation, sorry, turning identity record into operating evidence, because what NISTO will require after an incident is an incident notification within 70 to 72 hours.
So, you should declare an incident in 24 hours, then you should have a first analysis in the 72 hours, and then you have 30 days to come with a full analysis. So, to build that, the new question you need to ask and the new question that goes, sorry, behind, beyond the, through all the identity plan will be who acted, what identity plan was used, and what, which machine of product or instance was involved, what changed, and what record remained. And evidence should be provided to reconstruct all the process and to answer all that question.
This is not just a matter of answering yes or no, it's a matter of putting evidence on the table. So, I'm not going to walk through this matrix. What I want you to get is, from this slide, one architectural principle. Factory do not need a giant IAM platform that covers everything. What they need is a model that assigns each control point to the right identity plan, including machines and product.
So, let me give you a quick example. A machine identity needs strong issuance. We need to know how we bring a machine into the factory, and it also needs strong life cycle. You need to know how you update the machine, how you rotate it, how you retire it. On the other side, the authorization part for a machine is maybe pretty narrow in terms of role, far different than what you can add to some other plan, for example, to human or this kind of people.
You will not use the same tool for all the plans, but you need to make sure that you have all your control points belonging to the right plan in the right way. So, before I finish and bring you the conclusion and take away I want to give you, I would like to give you one example, one incident that triggered for identity plans. You take a production line gateway that is installed by an external integrator and standard procurement, standard onboarding, the device joins the network and starts pushing telemetry. It does what it's supposed to do. You pay for it. You get it.
18 months later, you have the first update. You have a maintenance contract. You're in the same integrator, remote station, sign the firmware, push the firmware, and then you get it.
Now, six months again later, you have this integrator that declares a vulnerability. The question is, okay, what happened now? And what are the questions you need to answer? What you will have to answer will be through the workforce identity. Who inside the plant approved the deployment of the product? What was the original installation? Who supervised the update? Is it still there? Do we have still, after two years, proof of that? The third-party identity plan will be which integrator account was used. Was this integrator account limited to that action or did it have broader rights?
On the machine part, you will have which gateway instance was involved. Can you tell apart this specific gateway instance from the other one you may have in your factory?
Finally, on the product identity, which firmware version was running at the moment the vulnerability was declared? Do you have evidence of that?
So, these are all the questions the regulator is expecting to get answered. When you will come to that, stating, hey, my factory under the needs to regulation got a vulnerability declared by a manufacturer under the GSA. That's far from being this person has access, the access was wanted, and that's okay. And I will let you with those, the three things I introduced at the beginning.
First, the industry 4.0 needs for identity plan covering workforce, suppliers, machines, and product. And the CIA makes product lifecycle identity fully part of the identity architecture you should build. And the last one is the needs to make evidence part of the identity design. You should bring evidence and you should track evidence. Thank you. Thank you.
