

When to use this service
A key position left vacant
The industrial systems security manager leaves, and the security program stops with them. Reinforcement holds the position and keeps ongoing work moving while recruitment takes place.
A regulatory deadline to meet
NIS2 or IEC 62443 compliance requires a workload the existing team can't absorb on top of day-to-day operations. Reinforcement carries the compliance file while the team keeps control of the installation.
An industrial project getting underway
A supervision migration, a control system overhaul, connecting new sites. The cybersecurity component has to be addressed from the design stage, with zone and conduit segmentation under IEC 62443, and no one is available to own it.
A specific skill you're missing
Industrial protocol analysis, architecture review of a substation, hardening an HMI fleet, preparing an OT crisis exercise. The need is one-off and technical, it doesn't justify a hire.


A typical cybersecurity engineer knows how to segment a network, harden a server, read a data flow. On an industrial site, that isn't enough. You also need to know what a PLC is, why you don't restart a supervision station in the middle of a production run, and how a protocol like Modbus TCP, IEC 60870-5-104, or Profinet behaves when it's scanned. This dual background, automation and security, remains rare. The teams who have it are already busy, often within the operator's own organization.
The consequence is familiar to every industrial operator: OT security programs move at the pace of one or two people in-house. A departure, sick leave, a SCADA migration project that lands at the same time as a NIS2 deadline, and the plan slips. Recruiting takes months. Training someone on a live production site costs precious mentoring time and puts operations at risk.
Reinforcement addresses this exact problem: providing a consultant who is already operational in industrial environments, for a defined duration, on a defined scope. They work within your governance structures, under your operating rules, alongside your teams. They don't replace your organization, they help it hold its workload over a given period.

How a reinforcement assignment works
<p>The principle is simple: a clearly scoped need, an identified profile, a gradual on-site integration, then a written handover at the end of the assignment. The consultant works within your organization and your operating rules, not alongside them.</p>
A technical discussion to define the scope: sites involved, systems at stake, topics to cover, reporting line, expected duration, and on-site presence schedule. We also identify what remains your responsibility, to avoid gray areas during the assignment.
We propose a consultant whose experience matches the context: type of installation, protocols, applicable standard, working language. You meet the consultant before confirming. No profile is assigned without your approval.
Safety induction, clearances, access to networks and technical areas, introduction to the operations and maintenance teams. The consultant starts by understanding the installation and its constraints before producing anything.
The consultant handles the topics defined during scoping, takes part in your project meetings, and reports on an agreed schedule. Any action touching a live production system goes through your internal validation and lockout procedures.
Before the assignment ends, the consultant hands over and walks through their documentation with the people taking over the topic. You stay in control: the report, flow diagrams, and configuration files remain usable in-house after the assignment.
What you receive
A consultant operational on your scope
A profile you approve yourself, present on site on the agreed schedule, integrated into your project governance, and reachable by your operations teams.
A regular progress update
A written report at a defined frequency: what has been handled, what is in progress, what is blocking, and what needs a decision from you.
The documentation produced during the assignment
Depending on the topics assigned: OT asset inventory · PLCs, HMIs, supervision stations, network equipment, remote access, flow diagrams, filtering rules, operating procedures, compliance files.
A handover file
The exact state of the scope when the consultant leaves: closed topics, open topics, decisions made, points to watch. Every remaining finding is tied to a risk level, a remediation effort, and an owner.
[ Help & support ]
Frequently asked questions
Can't find your answer here? We're available to talk about it. Tell us about your environment, constraints, and security challenges.
The consultant works under your operating rules, not their own. No action on production equipment is undertaken without the operator's approval and without going through your internal lockout and change management procedures.
For anything involving data collection on sensitive networks, the method stays the same as on our audits: traffic analysis from a mirror port, with no action on the process. Active testing is reserved for test environments, spare equipment, or planned shutdown windows.
No. The survey phase is done through data collection with no solicitation of field equipment, supplemented by interviews and configuration reviews. We work under real operating conditions, with no interruption to production.
Some actions in the remediation plan, however, will require a shutdown window: changing a network architecture or updating a PLC's firmware can't be done while running. That's precisely why the plan is split into three horizons: actions that require a shutdown are scheduled around your planned shutdowns, never imposed outside of them.
No. The survey relies on traffic capture in listen-only mode, with nothing sent to the equipment: traffic is captured via a mirror port or a TAP, with nothing sent to the PLCs. No active scan, no query to a piece of field equipment is launched without your written approval and outside production hours.
Physical work in cabinets and racks is scheduled with operations, and someone from your side is present. If an action carries the slightest risk to the process, it's postponed or dropped.
No. No action touches a live system without your approval and an agreed intervention window. Surveys are conducted through passive monitoring, with no queries sent to the PLCs.
Fixes that touch a PLC, a network, or a supervision system are scheduled around your shutdowns and carried out by your teams or your integrators. We prepare, we verify, we don't cut anything.
The risk is never zero on an industrial network, and no one serious will tell you otherwise. That's exactly why the method is built around this constraint: during normal operation, with no shutdown window.
In practice, the discovery phase is done by analyzing traffic from a mirror port, with no action on the process. Active actions are planned with operations, governed by written stop conditions, and a member of your team stays reachable throughout the engagement. Anything that can't be run without risk is run on a test bench, on a spare PLC, or during a scheduled shutdown. Anything that remains too risky isn't run at all: the scenario is documented and its impact described, without being executed.
That's actually the most common case. The first module is built to settle this point: Annex I and II sectors, size criteria, the case of subsidiaries and foreign groups. You leave with a written, justified qualification. We provide a technical and operational reading of the text, not a legal opinion: if your situation presents genuine ambiguity, it will need to be confirmed by your legal department or counsel.
No. The session is held in a classroom, with production maintained throughout, and no exercise is run on the production network. The setup adapts to shift changes: two identical sessions on the same day to cover two shift teams, or two spaced-out half-days. Control room positions stay staffed during the training.
Yes. The content covers mechanisms common to all ranges: lack of authentication in industrial protocols, protecting the project and programming mode, account management on the HMI, filtering between zones. The training rig uses specific hardware to make the demonstrations concrete, then each measure is transposed onto the equipment present at your site. If your fleet is homogeneous, we align the training rig and configuration sheets with your main vendor.
No. The day starts from the sensor and rebuilds the entire chain, with no assumed prior experience in PLC programming. The only useful prerequisite is general IT literacy: IP addressing and basic local network concepts. Your site's control engineers get value from it too, since the networks and protocols section covers points rarely addressed in vendor training.
Yes. No prior reading is required. The first module starts from the structure of the standard and the split of roles between operator, integrator, and vendor. What matters is knowledge of the installation: being able to read a schematic, and knowing the PLCs, links, and access points in service.
We don't place a generalist profile on an industrial need. The consultant we propose has already worked on control systems, knows the protocols involved, and understands what an availability constraint means on a live installation.
Another difference: the consultant isn't alone. They draw on the rest of the team for topics outside their scope, an architecture review or protocol analysis for instance, without changing your point of contact.
It depends on your sector of activity, your size, and the role you play in a critical chain. The national transposition specifies the categories of essential and important entities, and the obligations aren't identical for the two. Some of the operators concerned haven't yet been formally notified.
The first scoping step is used to settle this point, based on the evidence. If the applicable regime remains uncertain, we say so and tell you which obligations are worth putting in place regardless of classification.
Concretely: a few hours to gather existing documentation, 45-minute to 2-hour interviews per contact (operations, maintenance, automation, IT), and someone accompanying us on site during the survey phases, mainly for access and safety.
The workload is concentrated in the survey week. The rest of the work happens off-site, and the presentation needs two slots: one technical, one for management.
The pace is set during scoping, based on the size of your fleet, the number of sites, and ongoing projects. The typical pattern combines a periodic review meeting, scheduled on-site days, and availability for one-off questions between meetings.
There's no single format: a site running in a stable regime and a multi-site group in the middle of a supervision migration don't have the same needs.
An audit answers the question “where do we stand”: it covers the entire scope, architecture, configurations, and operating practices, and produces a complete assessment. A penetration test answers a different question: “how far can you go,” on a limited number of paths, with evidence.
The two complement each other, and the usual order is the audit first, then the test. A test launched with no prior knowledge of the installation costs time in discovery and needlessly increases operational risk.
There are no technical prerequisites. The day is designed for a mixed group: site management, production, maintenance, IT, compliance. It's actually the most useful setup, because the NIS2 scope gets decided at the intersection of these functions. A maintenance manager brings knowledge of the PLCs and integrator interventions that IT generally doesn't have.
Yes, that's exactly the intended audience. The day's thread starts from the process and the equipment participants handle: PLC, HMI, supervision station, network rack. Security concepts are introduced progressively, based on what they change in operations. An operator who knows their installation has more to contribute in modules 2 and 3 than an IT person who has never seen it.
No. All hands-on work happens on an isolated training rig brought by the instructor: PLC, HMI, supervision station, and network equipment. No action is taken on your production network, neither read nor write. The exercises that involve your actual installations are done on paper and on your diagrams.
Awareness training is aimed at all site personnel and covers behavior: USB drives, fraudulent messages, reporting, physical access. It requires no technical background. This day is aimed at people who work on the systems or make decisions about them, and it goes into the actual workings of the equipment, networks, and protocols. The two are complementary and can be taken in that order.
No. It's a hands-on practical training, not a certifying program. Participants receive a certificate of attendance and all the deliverables produced during the day. A personal certification comes from an accredited body, a product or process certification comes from a certification body.
Assignments range from a few days a month on a specific topic to continuous presence over several months to hold a position. The pace is set during scoping and can be revised if your workload changes.
We prefer to state real availability rather than theoretical availability: if the requested profile isn't available for the period you want, we say so at the scoping stage.
No, IEC 62443 is a standard, not a regulation. It becomes binding when a client, an insurer, or a contract requires it, which is increasingly common in the energy sector and among large industrial operators.
Its value lies elsewhere: it provides the vocabulary and method that NIS2 lacks on the technical side. NIS2 requires appropriate risk management measures, IEC 62443 says how to structure them on a control system. The two work well together, which is what we do within a single assignment.
No, and it's actually the most common case. On an installation that's been running for fifteen or twenty years, the gap between the original diagrams and reality is one of the expected findings, not an obstacle.
Reconstructing the actual architecture is part of the assignment: it's often even the deliverable teams reuse the longest after the audit.
No. We don't operate your installations and we don't have permanent access to your industrial network. Our role is analysis, trade-offs, and preparing decisions, not running the plant.
When access is needed for a survey, it's named, time-limited, and logged, following your internal rules. The operations teams are involved at every step.
On an industrial environment, a fully blind test yields little and carries a lot of risk. Without knowing the equipment present, a tester probes PLCs they shouldn't be touching.
We favor an informed approach: you provide the schematics, addressing plans, and inventory you have, and we check the gap against what's found on the ground. The “blind” part is kept where it makes sense, meaning at the starting point of the scenario, for instance from a standard office workstation with no special privileges.
No, and we don't present it that way. One day lets you define the scope, measure the gaps, and write a prioritized plan. Implementation is a project measured in months: network segmentation, remote access management, PLC program backups, vendor clauses. The training gives you the framework and the order of the work. Depending on the gaps found, the next step is an industrial cybersecurity audit or long-term support.
Yes, and it's preferable as long as the group doesn't exceed 12 people. The three trades don't see the same signals: operations sees a setpoint drift, maintenance sees a piece of equipment restarting, supervisors see an unplanned contractor intervention. It's by comparing these observations that the reporting chain gets built. For a large headcount, it's better to split by shift team than by trade.
It's built for them. The prerequisite is knowing your installation, not knowing IT security. The necessary networking concepts are introduced over the course of the day, starting from the control system chain that participants have drawn themselves. Feedback shows the difficulty tends to run the other way: a participant coming from IT discovers the process's availability constraints.
It's actually the most useful setup. A good part of the difficulties we observe during audits comes from a shared vocabulary that covers different realities, and from operating constraints that IT isn't aware of. The exercises in modules 4 and 5 are designed to bring together profiles that rarely cross paths day to day. A mixed group of 10 to 12 people works well.
It's the format we prefer, because the workshops become directly useful. The documents are shared beforehand under a confidentiality agreement, used during the session, then returned or destroyed as you instruct. If they can't leave the site, the session is held at your premises, on your own workstations. A sample installation is available as a fallback.
Part of the work is done remotely: configuration analysis, documentation drafting, compliance file preparation, diagram review. Anything that requires seeing the installation, understanding an operating mode, or interacting with the field teams is done on site.
The split between on-site presence and remote work is set during scoping, and it takes your remote access rules for OT networks into account.
Yes. A significant part of the industrial fleet is built on equipment designed before security entered the specifications. No one expects it to be replaced immediately, and the standard accounts for this case.
The answer lies in compensating measures: isolating the PLC in a dedicated zone, strict filtering of the conduits leading to it, controlling maintenance access, monitoring traffic. The requirement shifts to the perimeter, not the equipment. These measures are documented as such in the report, along with the residual risk they leave.
Yes, because the fix is almost never the patch. On a PLC that can't be patched or that's under a vendor contract, you act on what surrounds it: segmentation, flow filtering, removing unnecessary remote access, hardening engineering workstations, controlling USB drives and maintenance computers.
The audit tells you precisely which equipment can't be fixed, and which compensating measures reduce its exposure until it's replaced.
Yes, it's a significant part of the work. A good part of OT security issues plays out in specifications, installation acceptance tests, and remote maintenance conditions.
We review specifications, take part in technical meetings, and draft requirements verifiable on acceptance. We remain independent: we don't sell equipment or licenses and aren't tied to any vendor.
In practice, full isolation rarely holds up under scrutiny. The paths we find most often are remote maintenance access left open by an integrator, external contractors' laptops plugged directly into the industrial network, firmware update USB drives, 4G routers installed by an equipment vendor for its own monitoring, and production data servers that talk to both sides.
The test exists precisely to verify this assumption rather than take it for granted. For a substation operator, the assumed isolation was real on paper; a single engineering workstation shared between two zones was enough to bypass it.
Yes. The day is held in a classroom at your site, without touching process availability. The exercises are based on your plans, your inventories, and your organization, not on handling equipment. If you'd like, a short visit to the control room or a technical area can be included in the early afternoon, respecting your access rules and prevention plan. We keep the group at 8 to 12 participants: beyond that, the small-group exercises lose their value.
Modules 1, 4, and 5 follow a common thread, illustrated with anonymized cases from audits on comparable installations. Modules 2 and 3 are built around your site, based on a preliminary discussion with the operations manager: architecture diagram, type of PLCs and supervision, list of remote access and contractors. It's your architecture that gets drawn on the board, not an example.
It's the format we recommend. We ask beforehand for your schematics, your addressing plan, and the list of your remote access, under a confidentiality agreement. The zone segmentation and hardening exercises then work on your own installation, and the remediation plan produced at the end of the day is directly usable. Failing that, we work on a sample case close to your sector.
No. All hands-on work happens on the training rig brought by the instructor, isolated from your network. The traffic captures and diagrams used in the exercises come from real assignments and are anonymized. If the day is held on your site, an installation visit can be arranged at the end of the program, for observation only, with the agreement of operations and under their supervision.
Yes, it's the most useful format. Zone segmentation is decided between those who run the process and those who run the network, and the day is also meant for that confrontation. We limit the group to 12 people so the workshops stay manageable. Beyond that, we split the session in two.
No, and the setup is built to avoid it. The operations teams are involved at every step, documentation is produced as the assignment progresses rather than at the end, and a handover is organized with the people taking over the topics.
If you'd like to keep a connection after the consultant leaves, that falls under our long-term support and expertise offer, not an automatic extension of the reinforcement.
No, and it needs to be said clearly: compliance isn't a permanent state. A line extension, a new integrator, a supervision change, or an update to the standard call part of the file back into question. NIS2, in fact, requires an ongoing approach, with incident management and risk review over time.
What the assignment leaves you with is a reusable foundation. You stay in control: the report, flow diagrams, and configuration files remain usable in-house after the assignment. Your teams can update the zone segmentation and the evidence file without starting from scratch. If you'd prefer long-term support, that's the purpose of our long-term support and expertise offer.
No. You stay in control: the report, flow diagrams, and configuration files remain usable in-house after the assignment. Your teams or your regular integrator can handle the remediation plan without us.
If you'd like support to drive the actions, follow up with vendors, or prepare a compliance program, that falls under our long-term support engagements, and it's decided after the report, not before.
You carry on without us. You stay in control: the report, flow diagrams, and configuration files remain usable in-house after the engagement. Nothing is locked into a tool you can't access.
The goal, in fact, is to build your teams' autonomy on the subject, not to create a dependency.
No, and it needs to be said clearly. NIS2 requires risk management, technical and organizational measures, governance, and incident notification capability. IEC 62443 requires zone and conduit segmentation, target security levels, and component-level requirements. No penetration test covers all of that on its own.
That said, the test feeds into these efforts: it provides evidence of the effectiveness of measures in place, it documents the attack scenarios used in the risk analysis, and it gives the compliance file a factual element rather than a declarative one. It's part of a compliance program, not a replacement for one.
All the working materials are delivered in editable format: qualification grid, OT asset inventory template, Article 21 gap matrix, early-warning template, three-horizon plan table. They're designed to be picked up and updated by your teams. The day's content is revised with every update to the national transposition and implementing texts, and we flag during the session the points still likely to change, so you don't build your plan on an unstable reading.
No, and it needs to be said clearly. Staff awareness is one of the expected measures, but not the only one: governance, incident management, supply chain control, and technical measures require separate work. The session provides the elements to add to your file: detailed program, list of participants, attendance certificate, rules sheet drafted on site. The rest relies on an audit and a three-stage roadmap, from the immediate fix to the investment plan.
Technical Fundamentals lays out the OT landscape as a whole and is aimed at a broader audience, including non-technical staff. IEC 62443 in Practice covers the standards-based approach and its application at the scale of a site or an organization. This one focuses on a single subject, the control system, and on the configuration steps that protect it. The three follow in that order, but each can be taken independently.
Each participant leaves with the full course materials, the asset inventory template, the intervention checklist built during the session, and the captures used in the exercises. A certificate of completion is given to each participant, and a session summary is sent to the training manager. The logical next step depends on your needs: IEC 62443 in Practice for architecture and compliance, NIS2 for the regulatory side, or an audit if the goal is to establish the actual state of an installation.
The segmentation produced in the workshop is a starting point, not a compliance file. The usual next step is a survey of the installation to compare that segmentation against the actual flows, under real operating conditions, through data collection with no solicitation of field equipment. Your teams can also carry on alone: the files and templates remain usable in-house.
[ our other services ]
Our other industrial cybersecurity expertise
From the initial audit to long-term support, we cover the full cycle of securing your industrial systems. Every engagement is tailored to your environment and operating constraints





