OT Security in Manufacturing: NIS2 and CRA on AWS

NIS2 and CRA: What Applies When in Manufacturing?

The European cybersecurity landscape changed fundamentally in 2024. While NIS1 still primarily targeted energy suppliers and financial institutions, NIS2 now explicitly covers the manufacturing sector — with significantly tighter requirements and fines.

NIS2 Timeline and Scope

The NIS2 Directive should have been transposed into national law by October 2024. Germany is working on the NIS2UmsuCG (NIS2 Implementation and Cybersecurity Strengthening Act), expected to enter into force in 2025. For manufacturing companies, the following applies:

• Important entities (from 50 employees or EUR 10 million turnover): Machinery, automotive, medical devices, chemicals, food processing
• Essential entities (from 250 employees or EUR 50 million turnover): Enhanced requirements, proactive reporting obligations, personal liability of management
• Fines: Up to EUR 10 million or 2% of global annual turnover for important entities; up to 7% for critical sectors

Cyber Resilience Act (CRA)

The CRA (EU 2024/2847) applies from December 2027 to all products with digital elements. For manufacturing, this means: anyone who produces or places connected machines, controllers, sensors or industrial software on the market must demonstrate cybersecurity as an integral part of the product lifecycle. Key requirements:

• Security updates for at least 5 years of product lifetime
• SBOM (Software Bill of Materials) for every product
• Vulnerability reporting obligation to ENISA within 24 hours
• Conformity assessment and CE marking also for cybersecurity

Key Concepts: OT Security in the Manufacturing Context

OT Security (Operational Technology Security)

Protection of systems that monitor and control physical processes — PLCs, SCADA, DCS, industrial robots, CNC machines. OT security differs from classic IT security through hard real-time requirements, long lifecycles (10–30 years), proprietary protocols, and the potential for physical damage in the event of system failure or compromise.

Purdue Model (Purdue Enterprise Reference Architecture)

Reference architecture for segmenting industrial control systems into hierarchical layers (0–5): field devices (Level 0), control layer (Level 1–2), SCADA/MES (Level 3), enterprise IT (Level 4), cloud (Level 5). The Purdue Model defines which systems are permitted to communicate with each other — and which must remain strictly isolated.

DMZ (Demilitarised Zone) in OT

Buffer zone between the OT network (Level 3) and the IT network (Level 4/5). The OT DMZ filters and translates the data flow without allowing direct connections between the two networks. Data exchange takes place exclusively via controlled proxies, data diodes or application-layer gateways.

AWS IoT Device Defender

Managed AWS service for continuous monitoring and auditing of IoT devices and industrial endpoints. Device Defender checks configurations against security baselines, detects anomalous behaviour (unexpected connections, protocol deviations) and issues alerts on violations. Central control plane for device security on the shopfloor.

SBOM (Software Bill of Materials)

Machine-readable list of all software components, dependencies and versions that make up a product or system. The CRA requires SBOMs for all products with digital elements to enable rapid identification and remediation of known vulnerabilities (CVEs). AWS Inspector can automatically generate SBOMs for container and EC2 workloads.

NIS2 Reporting Obligation

Three-stage obligation to report significant security incidents: early warning (24 h), full incident notification (72 h), final report (1 month). An incident is considered significant if it substantially disrupts service delivery or causes substantial financial damage.

The Purdue Model on AWS: Reference Architecture for Secure OT/IT Integration

AWS does not recommend a full migration of OT systems to the cloud — but rather a hybrid model that maps the established Purdue layered model onto a cloud-native architecture. The five levels are mapped as follows:

The most critical transition is Level 3.5 — the OT DMZ. This is where it is decided whether OT systems are put at risk by the cloud connection or not. AWS Network Firewall implements deep packet inspection at this point with industry-specific rules (e.g. Modbus anomaly detection). Amazon GuardDuty monitors network traffic in the DMZ for threat patterns — including OT-specific attack vectors such as protocol abuse and lateral movement.

Segmentation Principles

• Least Privilege: Every device and service communicates only with the targets it needs for its function
• Default Deny: All connections are forbidden until explicitly permitted
• Unidirectional communication: Data transfer from OT to IT is permitted; control commands from IT to OT require separate, highly secured channels
• Network segmentation: OT network, IT network and cloud network as separate VPCs with controlled transitions

AWS IoT Device Defender: Continuous Device Security on the Shopfloor

Manufacturing companies often operate hundreds or thousands of IoT devices and OT endpoints. Each of these devices is a potential attack surface. AWS IoT Device Defender creates a central, automated overview of the security posture of all connected devices.

The Two Core Functions

Audit: Device Defender continuously checks the configuration of all IoT devices against best practices and defined security policies. Typical audit checks for manufacturing environments:

• Is a unique X.509 certificate used for each device?
• Are expired or revoked certificates still active?
• Do devices have excessively broad IAM permissions?
• Are devices communicating over unauthorised MQTT topics?
• Are devices registered in multiple accounts simultaneously (configuration anomaly)?

Detect: Using ML models and rule-based detectors, Device Defender monitors the runtime behaviour of each device. Deviations from the learned normal state automatically trigger alerts. Examples of relevant metrics:

• Number of outgoing TCP connections (indicator of C2 communication)
• Unexpected connection targets (geo-based or domain-based)
• Message rate (burst anomalies as an indicator of attacks)
• Authentication failures (brute-force attempts)

Alerts from Device Defender automatically flow into AWS Security Hub as findings and are coupled with CloudWatch alarms and SNS notifications. This enables a fully automated escalation chain — from anomaly detection to incident response activation within minutes rather than hours.

AWS Security Hub: OT/IT Security Posture at a Glance

NIS2 not only requires that security measures exist — but that they are demonstrable and documented. AWS Security Hub is the central dashboard for the security posture of all AWS resources and delivers exactly this accountability.

Security Hub aggregates findings from multiple AWS services and provides a prioritised, correlated overall assessment. Relevant for manufacturing environments:

Security Hub supports the AWS Foundational Security Best Practices (FSBP) standard and the CIS AWS Foundations Benchmark. For NIS2, Storm Reply additionally recommends the NIST CSF Framework as a compliance mapping — it covers all technical requirements from Art. 21 NIS2 and can be configured in Security Hub as a custom standard.

Incident Response and the 24-Hour Reporting Obligation

NIS2 Art. 23 prescribes a staged reporting obligation. Those who are unprepared fail not on the technology but on the processes. A structured incident response plan is mandatory — and AWS services provide the technical support for it.

NIS2 Reporting Obligation at a Glance

1. Early warning (24 hours): Report to BSI or competent CSIRT. Content: incident type, initial assessment of severity, first indication of possible cross-border impacts
2. Incident notification (72 hours): Updated assessment, severity level, indicators of compromise, measures taken
3. Final report (1 month): Full technical description, root cause analysis, countermeasures, lessons learned

AWS CloudTrail provides the immutable audit log for all actions in the AWS environment — essential for forensics. Amazon GuardDuty detects compromised credentials and unusual activity patterns and delivers timestamped findings with context. AWS Security Hub correlates these findings and automatically calculates severity.

Automated Incident Response Pipeline

1. GuardDuty or Device Defender detects anomaly and creates finding
2. Security Hub aggregates and prioritises the finding (CRITICAL/HIGH/MEDIUM)
3. EventBridge rule automatically triggers SNS notification to the security team on CRITICAL
4. AWS Systems Manager Automation executes initial response actions (e.g. isolate device, create snapshot)
5. CloudTrail and VPC Flow Logs preserve forensic evidence
6. Automatically generated report (via Lambda) pre-structures the 24h notification

With this pipeline, the time from detection to submitted BSI notification is reduced from typically 4–8 hours to under 1 hour — including nights and weekends.

Supply Chain Security and the Cyber Resilience Act

The CRA addresses a fundamental problem: many cyberattacks on manufacturing companies do not begin at the target itself, but at a supplier or software vendor. SolarWinds, Log4Shell and the Kaseya attack are prominent examples of this pattern.

NIS2 Art. 21 explicitly requires security in the supply chain. Manufacturing companies must:

• Assess the cybersecurity practices of their suppliers
• Enforce contractual security requirements on suppliers
• Document software dependencies of their products (SBOM)
• Ensure patch management for delivered components

AWS Services for Supply Chain Security

• AWS Inspector: Automated vulnerability scanning for EC2 instances, container images and Lambda functions. Automatically generates SBOMs in CycloneDX format — CRA-compatible.
• Amazon CodeGuru Security: Static code analysis for vulnerabilities in custom developments and imported libraries
• AWS CodeArtifact: Private package repository with provenance and integrity checks for all software dependencies
• AWS Signer: Cryptographic signing of code and software packages for verifiable provenance
• Amazon GuardDuty Malware Protection: Detects malware in EC2 instances and container workloads — including after supply chain compromise

EU Machinery Regulation 2023/1230: Cybersecurity as a Design Obligation

The EU Machinery Regulation 2023/1230 replaces the Machinery Directive 2006/42/EC and enters into force from October 2027. It extends the safety concept with an explicit cybersecurity dimension — with direct relevance for manufacturing companies that produce or operate machinery.

Annex III of the Regulation contains new essential safety requirements for connected machinery:

• Protection against unauthorised access to control systems (anti-tampering)
• Secure software update mechanism with integrity verification
• Logging of security-relevant events
• Documented risk analysis for cybersecurity as part of the CE conformity assessment
• Clear demarcation of interfaces between the machine and external systems

For cloud architecture this means: AWS IoT Greengrass enables secure over-the-air updates for edge devices with cryptographic signature verification. AWS IoT Device Management manages the lifecycle of all connected devices including certificate rotation. CloudTrail logs all configuration changes in a traceable manner — a direct contribution to conformity documentation.

Storm Reply Perspective: OT Security as Strategic Investment

Storm Reply has been advising manufacturing companies on secure cloud transformation for over 15 years. Experience from more than 50 OT/IT projects shows: the biggest mistake is treating OT security as a compliance exercise. Those who only meet the minimum requirements will have a problem after the next attack — and after the next regulatory wave too.

Successful projects do not start with a security tool, but with an inventory: which OT devices exist on the network? Which of them communicate where? Which still have default passwords? This foundation is missing in most manufacturing companies — and without it, no security measure is effective.

Our proven approach for OT security on AWS:

1. OT Asset Discovery (Week 1–2): Passive network scans with Claroty or Dragos, import into AWS IoT Device Management
2. Risk Assessment (Week 3–4): Criticality matrix, NIS2 scope analysis, CRA gap assessment
3. Quick Wins (Week 5–8): Network segmentation, Device Defender rollout, Security Hub activation
4. Incident Response Plan (Week 9–12): Playbooks for NIS2 reporting obligation, automated response pipeline
5. Continuous Monitoring: GuardDuty, Device Defender Detect, monthly compliance reports

Storm Reply is an AWS Premier Consulting Partner with competency in Security and Migration. We combine OT domain knowledge with AWS cloud expertise — and hold the certifications to work safely even in regulated manufacturing environments.

Benefits and Challenges at a Glance

Benefits of an AWS-Based OT Security Approach

• Scalability: Device Defender monitors hundreds or thousands of devices without proportional overhead
• Accountability: CloudTrail and Security Hub deliver audit-proof logs for BSI notifications and audits
• Integration: Native integration between IoT services, Security Hub, GuardDuty and CloudTrail without interface projects
• Cost efficiency: Pay-per-use instead of expensive on-premises SIEM licences
• Rapid deployment: Security Hub and GuardDuty can be activated within hours — no deployment project required

Typical Challenges

• Legacy OT devices: Many PLCs and SCADA systems do not support modern authentication standards — protocol gateways and network segmentation serve as compensating controls
• OT/IT organisational silos: OT teams and IT teams often have different responsibilities and cultures — shared security governance structures are a prerequisite
• Patching restrictions: Production facilities cannot be updated arbitrarily — maintenance windows and risk assessments are necessary
• Missing asset inventories: Without a complete inventory, effective risk management is impossible

FAQ: OT Security, NIS2 and CRA in Manufacturing

Does NIS2 apply to manufacturing companies?

Yes. NIS2 explicitly covers the manufacturing sector as an important entity from October 2024. Companies with more than 50 employees or EUR 10 million annual turnover in critical manufacturing areas (including machinery, vehicles, medical devices, chemicals) are subject to reporting obligations and must demonstrate appropriate security measures.

What is the difference between NIS2 and the Cyber Resilience Act?

NIS2 governs the operational security of network and information systems within organisations (processes, incident response, supply chain). The Cyber Resilience Act (CRA) regulates the security properties of products with digital elements — including connected machines, sensors and controllers that manufacturing companies produce or deploy.

What does AWS IoT Device Defender do for OT security?

AWS IoT Device Defender continuously monitors the security posture of IoT devices and OT endpoints. It detects deviations from defined security baselines (e.g. open ports, unexpected connections), audits configurations against best practices and triggers automatic alerts. This provides a central view of device security on the shopfloor.

How long do companies have to report a security incident under NIS2?

NIS2 prescribes a multi-stage reporting obligation: An early warning must reach the competent authority (BSI in Germany) within 24 hours. A full incident notification follows within 72 hours. A final report is due within one month. AWS Security Hub and CloudTrail support the automated generation of these records.

What does the EU Machinery Regulation 2023/1230 require from manufacturers?

The EU Machinery Regulation 2023/1230 (applicable from October 2027) extends machinery safety to connected machines with software. Manufacturers must demonstrate cybersecurity as an integral part of the design, implement secure software update mechanisms and document digital risk analyses. AWS services such as CodeArtifact, Inspector and Systems Manager support these requirements.

Can AWS IoT Greengrass continue operating during a network outage?

Yes. AWS IoT Greengrass is designed as an edge runtime and works even without a connection to the AWS cloud. Local processing, Lambda execution and data buffering function offline. Once the connection is restored, buffered data and status changes are synchronised. This is essential for OT environments with strict availability requirements.

Sources and Further Reading

• EU Directive 2022/2555 (NIS2): eur-lex.europa.eu
• EU Regulation 2024/2847 (Cyber Resilience Act): eur-lex.europa.eu
• EU Machinery Regulation 2023/1230: eur-lex.europa.eu
• BSI: IT-Grundschutz for Industrial Control Systems (ICS): bsi.bund.de
• AWS Security Hub Documentation: docs.aws.amazon.com
• AWS IoT Device Defender Documentation: docs.aws.amazon.com