The diagnosis is done. The technical plan has been approved by the CEO + CFO + IT trio. You know your factory falls under NIS2 and you know, in broad terms, how the OT/IT network should be segmented. What is missing is the part nobody wants to write on a slide: the concrete controls. Which firewall rule, which log retention policy, which MFA on which system, which RTO for the MES server. In this article, the operational level of NIS2 is resolved in technical detail — parameters, snippets, thresholds and the traps we have already seen blow up in production.

The thesis, and I will pay it off throughout the text: most Portuguese factories fail NIS2 not for lack of technology, but for lack of auditable evidence. You have antivirus, you have backups, you have VPN. What you do not have is the proof, with date and time, that it works, was tested and someone is responsible for it. NIS2 does not ask whether you have controls. It asks whether you can demonstrate them when the CNCS knocks on your door after an incident. And here the difference between your name on a list of incidents and silence is the quality of your records, not the brand of your firewall.

It is worth putting some numbers on the table before continuing. The National Cybersecurity Centre, through CERT.PT, recorded 2,758 incidents in 2024 — 36% more than the previous year, with the overwhelming majority (78%) affecting private entities. It is not a problem for banks or telecommunications operators. It is a problem for the garment maker in Barcelos, the warehouse in Lousada, the metalworking firm in Águeda. And it is on those that NIS2 and its national transposition, Decree-Law No. 65/2025, will exert real regulatory pressure — with fines that, in the European version of the directive, can reach 10 million euros or 2% of the total worldwide annual turnover for essential entities.

I assume you have already read the diagnosis and the technical plan and that the OT/IT network architecture has already been designed. What is missing is the layer of controls that sits on top of that segmentation. Think of three concentric rings, from the outside to the heart of the factory. It is not a pretty metaphor for slide consumption — it is how you distribute budget, responsibility and implementation priority.

Ring 1 — Perimeter and identity

Next-generation firewall at the border, mandatory MFA on everything that is remote access and on a central identity directory. The classic mistake is to have MFA on email and leave ERP access with a username and password shared between three people in the warehouse. Identity is the new perimeter — including for the warehouse supervisor who hates typing codes and who will fight against any control that takes him off the radio for more than two minutes.

The traditional perimeter — that wall between "inside" and "outside" the network — died the day the sales rep started accessing the ERP from a mobile phone at the Milan fair and the cutting machine integrator asked for a VPN to provide support from Italy. Today there are dozens of legitimate entry points. Each one of them is a door. What changes security is not the number of doors, it is knowing who passes through each one, when, and with what authorisation. That is called identity, and it is where most factories spend the least and should spend the most.

Ring 2 — Segmented and monitored network

The OT cell (PLCs, KORA Productivity terminals, scales, readers) lives in a VLAN with no direct exit to the Internet. All OT↔IT traffic passes through an inspection point. Here there is no generic VPN: there are specific tunnels, per service, with logging. If a production capture terminal needs to talk to the ERP, that door is opened and only that one.

In a footwear factory in Felgueiras, the shop floor can easily have 40 to 60 devices connected to the network: perforation terminals, computerised sewing machines, glue scales, barcode readers on assembly lines, the MES stations. Each of these devices was bought on a different date, runs different software and has a different life cycle from the office PC. Putting them all on the same VLAN as the finance department's file server is inviting disaster. Segmentation is not architectural purism — it is damage containment. When something gets in, and something will get in, the question is: how far can it reach?

Ring 3 — Data, backup and recovery

The heart: ERP database, file server, server images. Backup 3-2-1, with the immutable copy outside the domain. A ransomware attack that catches Active Directory almost always catches the backups that are on the same domain. The offline or immutable copy is what separates "we restored in 6 hours" from "we paid".

The 3-2-1 rule is simple to recite and hard to comply with: three copies of the data, on two different types of media, with one copy off-site. The modern version adds the immutable "1" — a copy that, once written, cannot be altered or deleted for a defined period, not even by an administrator with valid credentials. This is the defence against the scenario where the attacker gets in with administrator privileges and, before encrypting, deletes the backups to force payment. We have seen it happen. The immutable copy is the only control that resists a compromised administrator.

An expensive firewall without retained logs is a fire extinguisher hung on the wall with no charge. It looks good in the visual audit. It puts nothing out.

The decision table by ring

For the CEO + CFO + IT decision trio, it helps to have the effort and return mapped by ring before approving budget. Do not spend on ring 3 if ring 1 is wide open — but also do not leave ring 3 for "phase 2" that never comes.

RingAnchor controlRelative costRisk if absent
1 — Perimeter / identityMFA + central directory + NGFWMediumCredential compromise → full access
2 — Segmented networkIsolated OT VLAN + OT↔IT inspectionMedium-highLateral movement from the office to the shop floor
3 — Data / recoveryImmutable 3-2-1 backup + restore testHighIrreversible data loss; prolonged downtime

2. Parameters, metrics and thresholds

Here is the table that should be stuck to your IT lead's monitor. Defensible numbers, aligned with the logic of NIS2 and with what ISO 27001 expects in terms of operational control. Adjust to your context — but do not loosen the ones marked as critical.

ControlParameter / thresholdCriticality
Security log retentionMinimum 12 months; 6 hot, 6 in archiveCritical
MFA on remote and privileged access100% of accounts; zero permanent exceptionsCritical
Critical patch application window≤ 15 days after publication (CVSS ≥ 7.0)Critical
RTO — ERP / MES server≤ 4 hoursHigh
RPO — ERP database≤ 1 hourHigh
Backup restore testQuarterly, with documented evidenceCritical
Initial incident notification (early warning)24 hours to the CNCSLegal (NIS2)
Detailed notification72 hoursLegal (NIS2)
Privileged credential rotation≤ 90 days, or immediate on employee departureHigh
Access review (recertification)Half-yearlyMedium

The 24 and 72-hour deadlines are not our recommendation — they are an obligation of Directive (EU) 2022/2555, transposed in Portugal by Decree-Law No. 65/2025. Missing the 24-hour early warning window is, in itself, a compliance failure, even if the incident ends up being controlled. The directive also foresees a third moment: the final report, up to one month after the initial notification, with the full description of the incident, root cause and mitigation measures applied.

Why 15 days for patches?

Because below that the factory cannot test and schedule a stoppage without breaking lines; above that, the exposure window to known exploits becomes indefensible in an audit. Fifteen days is the operational compromise between availability and risk. For OT with only schedulable stoppage, document the exception with compensation (isolation, reinforced monitoring) — NIS2 tolerates managed risk, not ignored risk.

There is a nuance that separates office IT from shop-floor OT. An email server applies a patch and restarts in the early hours of a Sunday without anyone noticing. A plastic injection machine in the metal/plastic industry in the middle of a run of 40,000 pieces does not restart because a patch came out. The stoppage has a direct cost — cooling mould, interrupted cycle, scrap. That is why OT lives by another logic: when it cannot apply the patch within the deadline, isolate the device aggressively and monitor it as if it were already compromised. It is the difference between ignored risk and managed risk, and NIS2 lives on that distinction.

RTO and RPO: translating into business language

RTO — Recovery Time Objective — is the maximum time you accept having the system down. RPO — Recovery Point Objective — is the maximum amount of data you accept losing, measured in time. An RPO of one hour means that, in the worst case, you lose the last hour of recorded work. Translate this into month-end at a garment maker near Famalicão: if the ERP goes down at 4 p.m. on the 30th and the last backup is from 3 p.m., you have lost an hour of production entries at a time when half a dozen people are closing hours, quantities and subcontracting invoicing for the parent company. An hour on that day is not just any hour.

Defining RTO and RPO is not a technical exercise — it is a business decision disguised as a technical decision. The shorter they are, the more expensive. An RPO of one minute requires synchronous replication; an RPO of 24 hours needs only a nightly backup. The right question is not "how long does it take to recover", it is "how much does each hour of downtime cost" — and that question is answered by the CFO, not the systems administrator.

Defining the RTO is a CFO decision dressed up as an IT decision. Whoever signs off the cost of each hour of downtime is the one who should sign off the recovery objective.

3. Practical configuration

Illustrative snippets. No credentials, no real IPs. Adapt to your infrastructure and never copy-paste into production without review.

OT segmentation: restrictive firewall rule

# Default policy: deny everything between OT and IT VLAN.

Only open what is strictly necessary, per service and destination.

VLAN_OT = 10.20.0.0/24 (shop-floor terminals)

SRV_ERP = 10.10.5.30 (MULTI ERP application server)

Allow only production capture terminal -> ERP (app port)

allow from VLAN_OT to SRV_ERP port 8443 proto tcp # internal HTTPS

Deny any OT exit to the Internet

deny from VLAN_OT to any port any # final catch-all rule

Log everything that hits the catch-all (evidence of attempt)

log deny VLAN_OT

The operational principle here is called default deny: deny everything, open the minimum. It is the inverse of the common practice of "open everything and close what causes problems", which always produces a network full of forgotten doors. The final rule that logs what hits the catch-all does not only serve security — it serves as diagnosis. If a legitimate device is trying to communicate and failing, it appears in the log and you discover a dependency you did not know existed.

Log retention and centralisation (rsyslog to SIEM)

# Forward authentication and firewall logs to the central collector.

Without centralisation, each machine deletes its own proof.

/etc/rsyslog.d/60-nis2.conf

auth,authpriv.* @@10.10.9.15:6514 # TLS to the SIEM collector

Retain locally 90 days before rotation

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

(rotation and 12-month retention managed on the central collector)

Log centralisation is the most undervalued control and the one that is most frequently missing. The reason is boring: it prevents nothing. A SIEM does not block an attack — it records it. But without that centralised record, on the day of the incident, you go jumping from machine to machine copying text files that contradict each other on time zones, while the CNCS waits for the 24-hour notification. The centralised log is the difference between reconstructing what happened in two hours or in two weeks.

Automatic restore verification (job skeleton)

# Restore the latest ERP DB backup to an isolated environment

and validate integrity. Run quarterly, save log with date.

restore_db --source /backup/erp/latest.bak --target sandbox_erp

Validate that the invoicing table has records from the last month

check_row_count sandbox_erp faturas --min 1 --since -30d

Record result as audit evidence (with timestamp)

echo "$(date -Is) restore OK" >> /var/log/nis2/restore-evidence.log

Note the last step of each snippet: the record with date. NIS2 does not live on the commands. It lives on the proof that the commands ran. The second step — validating that the invoicing table has recent records — is what distinguishes a serious restore test from theatre. Copying a file and saying "restored" proves nothing. Restoring and then opening the database and confirming that the data is there and makes sense: that is auditable evidence.

The hierarchy of evidence

Not all evidence has the same value in a post-incident audit. An administrator saying "yes, we test the backups" is worth zero. A weekly automatic report that says "success" is worth little, because it does not prove the file was restorable. A timestamped log of a real restore to an isolated environment, with content validation, is worth everything. Build your controls thinking about which of these three levels you will be able to show the auditor.

4. Integrations and dependencies

None of these controls lives in isolation. The dependency map is where real implementations stumble — because the factory forgets that the ERP server depends on Active Directory, which depends on DNS, which depends on a switch nobody knows where it is physically.

  • Identity → everything: the central directory authenticates ERP, MES, WMS and mail. If it goes down, access to everything goes down. It needs its own redundancy and a documented emergency access procedure (break-glass).
  • MULTI ERP → database → immutable backup: the MULTI ERP is the repository of the Bill of Materials, orders and AT certification. The backup chain must cover the complete DB, not just the files.
  • KORA Productivity → ERP: production capture feeds the OEE and planning. The OT↔IT tunnel of this connection is the most critical — and the most attempted by attackers who have already got into the shop floor.
  • SIEM / log collector → all systems: without centralisation, there is no event correlation. A failed login on the ERP and a failed login on email, in isolation, say nothing. Correlated, they are an attack in progress.
  • BI → audit logs: with Qlik Sense reading the access logs via ETL, you build a security Business Intelligence dashboard that the CISO consults in 30 seconds instead of digging through text files.

The break-glass procedure nobody has

Emergency access — break-glass — is the set of sealed credentials used only when everything else fails. It should be documented, kept physically in a safe or in a digital vault with multiple approval, and its use should trigger an immediate alert. Most factories do not have this. They have, instead, the domain administrator password in one person's head. On the day that person is on holiday in the Algarve with no signal and AD goes down, it turns out the continuity plan was one person. Formalise the break-glass: who can access, how it is authorised, and how its use is recorded.

The question that separates the plan from the theatre: if Active Directory goes down at 3 a.m. on Saturday, who gets into the system and how? If the answer is "João knows the admin password", you do not have a plan. You have João.

The supply chain as a hidden dependency

NIS2 explicitly extends responsibility to the supply chain. Having your own house in order is not enough — you need to know that the integrator who maintains your cutting machine, the cloud provider that hosts your backup and the consultant who accesses the ERP have minimum security practices. This is a difficult cultural shift for the Portuguese industrial SME, used to personal trust relationships with decades-old suppliers. The directive requires that this trust now has a contract, a clause and proof. Start with the suppliers who have remote access to your systems — they are the most direct vector.

5. Operational traps

What we have seen blow up in real factories — anonymised, but true in nature.

1. Backups on the same domain

At a metalworking unit, ransomware encrypted the servers and, in the same run, the network backups — because they were on the same Windows domain. Restore impossible. Solution: at least one immutable or offline copy, outside the control of the compromisable domain. The rule of thumb: if a compromised domain administrator can delete the backup, that backup does not count as a security copy for ransomware recovery purposes.

2. MFA with permanent "temporary" exceptions

The MFA exception for the sales director "just this week because he is at a fair" that lasts three years. It is always the account with an exception that gets compromised. Solution: MFA exceptions with automatic expiry date. No exception without a deadline. And monitor the exceptions list monthly — the natural entropy of any organisation accumulates exceptions like the warehouse accumulates orphan pallets.

3. Logs that nobody reads and that delete themselves

Firewall logging everything — and rotating the logs every 7 days for lack of disk. When there was an incident, the evidence had disappeared a month earlier. Solution: centralisation in a SIEM with 12-month retention, budgeted from the start. The cost of log storage is ridiculous compared to the cost of not being able to prove what happened in a notification to the regulator.

4. The shop-floor terminal with out-of-support Windows

The terminal that controls an expensive machine runs a system that no longer receives patches, because "the machine supplier does not certify newer versions". A perfect entry point. Solution: aggressive isolation on a VLAN with no Internet, dedicated monitoring, and contractual pressure on the machine manufacturer. This is a structural problem of textiles and metalworking, where 15-year-old machines with embedded Windows XP controls still produce value every day. You are not going to throw them away — you are going to isolate them.

5. Restore never tested

Backups running for years, green in the report. On the day of the disaster, it turns out the DB backup had been corrupted for eight months. The report said "success" because it copied a file — not because the file was restorable. Solution: a real quarterly restore test, as we detail in disaster recovery in the factory. Without a tested restore, you do not have a backup. You have hope.

6. Shared credentials in the warehouse

A login "armazem1" used by 12 people. When something goes wrong, nobody knows who it was. And when someone leaves the company, the password stays. Solution: individual identity, even on the KORA Inventory Suite terminal — badge reading is faster than typing and is auditable. In the Lousada/Paços distribution corridor, where the warehouse supervisor does not want to waste time, the badge solves both problems: speed for him, traceability for the audit.

7. Suppliers with permanent VPN access

The cutting machine integrator has a VPN open 24/7 "to provide support". One of the biggest attack vectors is the supply chain. Solution: supplier access on request, with a time window, session recording and automatic revocation. This connects directly to the logic of zero trust in OT networks.

8. The account of someone who has already left

The employee left eight months ago. The account is still active, with access to the ERP, because HR notified IT by email that nobody read. Ghost accounts are the perfect gift for an attacker: legitimate privileges with nobody monitoring the behaviour. Solution: link the HR departure process to the automatic deactivation of access. When offboarding in the people system triggers revocation in the directory, the gap closes itself.

The table of traps by probability

If you have to prioritise — and you will — attack first what is most likely and cheapest to fix. This is the order we recommend at a typical industrial SME.

TrapProbabilityCost of fixPriority
Restore never testedVery highLow (process only)1
Shared credentialsVery highLow2
Accounts of people who have leftHighLow (automation)3
Backups on the same domainMediumMedium4
Permanent MFA exceptionsHighLow5
Out-of-support OT terminalHighHigh (isolate) / Very high (replace)6
Supplier VPN 24/7MediumMedium7

6. Final technical decision

No hedging. The choice of controls scales with size and risk profile. Small factories are the disproportionate target, not the exception — precisely because they assume they are too small to interest anyone. A ransomware operator does not choose targets by size; it chooses by ease of entry and probability of payment. A family factory with no SOC, with backups on the domain and production stopped costing thousands per hour, is the ideal target: weak defence, strong incentive to pay.

Size / profileMonitoring approachBackupIdentity
Up to ~50 PCs, no critical OTLightweight EDR agent + basic centralised logs3-2-1 with immutable cloud copyMFA + single directory
50–200 PCs, with OT (textiles, footwear)EDR + own log collector; externally managed SIEM3-2-1 + off-site replica + quarterly testMFA + PAM for privileged accounts
200+ PCs, extensive OT, multi-siteDedicated SIEM + SOC (internal or MSSP); event correlation3-2-1 + immutable + DR site with RTO ≤ 4hFull PAM + half-yearly recertification

The SME that thinks it is too small

There is a temptation, in the up-to-50-PCs tier, to say "this is for the big ones". It is not. It is true that a garment maker with 30 employees is not going to set up a SOC. But EDR on a lightweight agent, immutable cloud backups and MFA on the directory are accessible, provable and cover the overwhelming majority of real vectors. NIS2, in the national transposition, defines scopes by size and criticality — and even those who fall outside the direct scope are frequently dragged in via the supply chain, when the parent company (Inditex, Decathlon, Tom Tailor) demands security proof from the clothing subcontractor. Compliance stopped being optional the day it became a purchasing requirement.

The intermediate tier: the most uncomfortable

The 50-to-200-PC tier with OT is the hardest to solve. It is too big to get away with the minimum, but too small to justify a full-time internal SOC. The rational answer is the hybrid model: own capacity for day-to-day (EDR, log collector, identity management) and an external managed service for 24/7 monitoring and incident response. The global shortage of cybersecurity professionals makes the internal hiring of an incident response team practically impossible for a factory of this size — the talent market does not exist at the price the company can pay.

Above 200 PCs: no shortcuts

Hard rule: above 200 PCs, the lightweight agent is not enough — implement a SIEM with correlation and a 24/7 response capability, own or contracted. At this size, with multiple sites and extensive OT, the attack surface is too large for manual surveillance. Automatic event correlation — linking the failed login on the ERP to the failed login on email to the anomalous data transfer at 4 a.m. — is what turns hundreds of thousands of log lines per day into three alerts worth investigating.

There is a measurable saving in automating detection. Organisations that used AI and automation extensively in prevention saved, on average, significant amounts per breach, according to IBM's annual breach cost reports — in a context where the global average cost of a breach remained in the order of millions of dollars. Detection automation is not a luxury — it is loss-containment mathematics.

If you are still deciding the solution by licence price, you are comparing the wrong thing. Compare the cost of 8 hours of a stopped line at a collection peak with the cost of the control that prevents them.

The funding calendar does not wait for the audit

A practical note from someone who has already seen applications drag on. Investments in cybersecurity and infrastructure frequently fit within the instruments of PT2030, COMPETE 2030 and Norte 2030, and there are specific lines for digitalisation and resilience. What holds back applications is rarely the merit — it is the poorly prepared technical report, the absence of comparable quotes, the lack of a clear link between the investment and a concrete regulatory obligation. NIS2 gives you, ironically, the best application argument you have ever had: an investment that is not discretionary, it is imposed by a transposed European directive. Use that in the descriptive memorandum.

7. How INFOS implements it

We work on NIS2 in the factory from the inside out: the MULTI ERP and KORA Productivity sit on infrastructure that we design with OT/IT segmentation, central identity and immutable backup, and we link the access logs to Qlik Sense dashboards so that the compliance evidence is one click away — not hidden in text files that nobody opens. The cybersecurity and datacenter services close the loop with monitoring and tested recovery. For those who also manage the people behind the access, the cross-referencing between HR and access — with pplPortal — removes one of the biggest gaps: accounts of people who have already left the company.

Why inside out and not the other way round

The most common approach in the market is to sell security as a layer stuck on top of what already exists: install this product, contract this service, close the audit. It works on paper and fails in the factory, because security stuck on top is always the first thing to be bypassed when it gets in the way of production. When the controls are born from the way the ERP, the MES and the WMS already work — when individual identity at the warehouse terminal is at once faster and more secure — compliance stops being a tax and becomes a by-product. That is the difference that 35 years implementing vertical software for industry have taught us: the control that gets in the operator's way ends up switched off; the control that helps them stays.

NIS2 is going to force many a Portuguese factory to do what it should have been doing for years. The difference between those who suffer the directive and those who use it is simple: the former spend on audits to prove they are compliant; the latter configure the systems so that compliance is an automatic by-product of how they already work. The question that remains is not whether you will have an incident — it is whether, when you have it, you will have the date and time to prove you did everything you should have. It is that proof, and not the brand of the firewall, that decides the rest.

Sources

  • Directive (EU) 2022/2555 (NIS2), Official Journal of the European Union; national transposition by Decree-Law No. 65/2025, Diário da República.
  • National Cybersecurity Centre (CNCS) / CERT.PT — 2024 incident report.
  • IBM — Cost of a Data Breach Report (annual editions).
  • Verizon — Data Breach Investigations Report (DBIR).
  • ISC2 — Cybersecurity Workforce Study.
  • ISO/IEC 27001 — Information security management system.

Frequently asked questions

What does the 3-2-1 rule for backups mean and how do I implement it?

The 3-2-1 rule requires three copies of the data, on two different types of media, with one copy off-site. The modern version adds an immutable copy — which cannot be altered or deleted for a defined period, not even by an administrator. This immutable copy protects against ransomware attacks where the attacker gets in with administrator privileges and deletes the backups.

Why is identity more important than the firewall?

Identity is the new perimeter because there are dozens of legitimate entry points into your factory: the sales rep's mobile phone, the integrator's VPN, remote access. What changes security is not the number of doors, it is knowing who passes through each one, when and with what authorisation. An expensive firewall without auditable records does not protect you in an audit.

What is an OT VLAN and why do I need it?

An OT VLAN is an isolated network for shop-floor devices (terminals, machines, scales, readers). In a factory there may be 40 to 60 devices bought on different dates with different software. Isolating them on a VLAN with no direct exit to the Internet is damage containment: when something gets in, it limits how far it can reach.

Is MFA mandatory on all access?

Yes. The classic mistake is to have MFA on email and leave ERP access with a shared username and password. Identity is the new perimeter — including for the warehouse supervisor. Each remote access, each critical service, must require multi-factor authentication through a central identity directory.

How do I inspect traffic between OT and IT?

All OT↔IT traffic passes through a central inspection point. There is no generic VPN: there are specific tunnels per service, with logging. If a production capture terminal needs to talk to the ERP, only that door is opened and no other. Each connection is documented with date and time.

What is the risk of not having a backup copy off-site?

A ransomware attack that catches Active Directory almost always catches the backups on the same domain. Without an offline or immutable copy, the difference is between "we restored in 6 hours" and "we paid a ransom". The off-site copy is the defence against the scenario where the attacker gets in with administrator privileges.

What is an immutable backup copy?

A copy that, once written, cannot be altered or deleted for a defined period, not even by an administrator with valid credentials. It is the only defence that resists a compromised administrator. It protects against attackers who get in with elevated privileges and try to delete the backups before encrypting the data.

Why do most Portuguese factories fail NIS2?

Not for lack of technology, but for lack of auditable evidence. They have antivirus, backups, VPN. What they do not have is the proof with date and time that it works, was tested and someone is responsible. NIS2 does not ask whether you have controls — it asks whether you can demonstrate them when the CNCS knocks on your door after an incident.