Module 4: Essential Cybersecurity Requirements for Software Manufacturers

Step 1 – Where These Requirements Come From (CRA Context)

In the EU Cyber Resilience Act (CRA), manufacturers of products with digital elements (including most software) must meet essential cybersecurity requirements throughout the whole lifecycle of the product.

Key points (2024–2027 context):

• The CRA is an EU Regulation (directly applicable in Member States), not a directive.
• It sets high‑level essential requirements; detailed technical rules will come via harmonised standards (e.g. future EN/ISO/IEC standards aligned with CRA).
• Manufacturers must show that their software meets these essential requirements to place it on the EU market.

In this module you will learn to:

1. List the main essential cybersecurity requirements that apply to software under the CRA.
2. Explain what security‑by‑design and security‑by‑default mean in practice for architecture and configuration.
3. Apply these ideas to simple, realistic software scenarios.

Keep in mind: the CRA builds on existing ideas (like ENISA good practices, ISO/IEC 27001/62443, and the NIS2 mindset) but turns them into legal obligations for software manufacturers.

Step 2 – The Essential Cybersecurity Requirements: A Quick Map

The CRA groups essential requirements around the product lifecycle. For software manufacturers, the main categories are:

1. Design & development

• Security‑by‑design (architecture, coding, dependencies)
• Security‑by‑default (secure configurations, minimal privileges)
• Minimise attack surface and harden interfaces
• Handle data securely (confidentiality, integrity, availability)

1. Production & placing on the market

• Perform and document risk assessment
• Use secure development processes (version control, code review, CI/CD security checks)
• Integrate vulnerability handling and testing before release

1. Use phase (operation & maintenance)

• Provide security updates and patches for a defined support period
• Ensure secure update mechanisms (e.g. signed updates)
• Offer clear security instructions for users and administrators

1. Vulnerability handling & reporting

• Have a coordinated vulnerability disclosure (CVD) process
• Monitor for new vulnerabilities (including in third‑party components)
• Fix and communicate vulnerabilities within reasonable timeframes.

Later, harmonised standards (for example, updated versions of EN/IEC 62443 or EN ISO/IEC 27001/27002 profiles for products) will translate these into more concrete technical controls. But in an exam or assignment, you should be able to name and explain these high‑level requirements without relying on those standards.

Step 3 – Security‑by‑Design: What It Means in Practice

Security‑by‑design under the CRA means you treat security as a core design constraint, not an afterthought.

In practical software terms, this includes:

1. Threat‑driven architecture

• Perform threat modelling (e.g. STRIDE) early in design.
• Identify assets (data, services), entry points (APIs, GUIs), and likely attackers.
• Choose architectures that limit impact if something goes wrong (segmentation, micro‑services with restricted access, etc.).

1. Secure coding and dependencies

• Follow secure coding guidelines (e.g. OWASP ASVS, language‑specific standards).
• Avoid known‑vulnerable libraries; use Software Bill of Materials (SBOM) to track components.
• Enforce input validation, output encoding, and safe error handling.

1. Built‑in protection mechanisms

• Authentication & authorisation (role‑based access, least privilege).
• Cryptography used correctly (modern algorithms, proper key management).
• Logging & monitoring designed from the start (what to log, how to protect logs).

1. Resilience & fail‑safe behaviour

• Design for graceful degradation: if a component fails, the system moves to a safe state.
• Avoid single points of failure for critical security functions.

The CRA expects that you can show documentation of these design decisions (e.g. architecture diagrams, threat models, design records).

Step 4 – Example: Applying Security‑by‑Design to a Web App

Imagine you are building a cloud‑hosted note‑taking application that syncs across devices. How would security‑by‑design look?

1. Architecture choices

• Use a 3‑tier architecture (front‑end, API, database) with network segmentation between tiers.
• Put the API behind an API gateway that enforces authentication and rate limiting.

1. Threat modelling outcome (simplified)

• Assets: user notes, user accounts, authentication tokens.
• Threats: account takeover, data leakage between users, data loss, DoS.
• Design responses: strong password policy + MFA support; per‑tenant access control; regular backups; rate limiting.

1. Secure coding & dependencies

• Use a modern framework with built‑in protections (CSRF tokens, parameterised queries).
• Integrate a dependency scanner (e.g. GitHub Dependabot, Snyk) into CI to detect vulnerable libraries.

1. Built‑in protections

• All network traffic over TLS 1.2+ (HTTPS).
• Passwords stored using a slow, salted hash (e.g. Argon2, bcrypt).
• Access control checks in a central middleware layer, not scattered ad‑hoc.

This is the kind of concrete thinking the CRA expects from manufacturers to show they applied security‑by‑design.

Step 5 – Security‑by‑Default: Secure Out of the Box

Security‑by‑default means that when the product is first installed or exposed to users, it is already in a secure state, without requiring advanced configuration.

Under the CRA, that typically implies:

1. Safe default configurations

• No default passwords that are the same for all users (e.g. `admin/admin` is not acceptable).
• Disable unnecessary services, ports, and features by default.
• Use secure protocol versions by default (e.g. TLS instead of plain HTTP).

1. Minimal privileges and access

• Applications and services run with least privilege accounts.
• New user accounts get the lowest necessary role by default (e.g. standard user, not admin).

1. Privacy and data protection defaults

• Collect only data that is strictly necessary for core functionality.
• Log what you need for security and troubleshooting, but avoid sensitive personal data where possible.

1. Update and security features enabled

• Security updates enabled by default (or at least strongly recommended with clear prompts).
• Basic protections (e.g. input validation, CSRF protection, encryption) cannot be disabled easily or accidentally.

The idea is that a non‑expert user who just clicks “Next, Next, Finish” ends up with a reasonably secure system, not a dangerously open one.

Step 6 – Thought Exercise: Spot the Security‑by‑Default Violations

Consider a newly installed on‑premises project management tool with these characteristics:

1. It creates a default admin account with username `admin` and password `admin123` and shows this on the last setup screen.
2. It exposes an unauthenticated status page on port 8080 with system info and logs.
3. Automatic updates are disabled by default; the admin must enable them in an advanced settings menu.
4. All new users are created with the “Project Manager” role, which can delete projects and manage users.

Your task:

• List at least three ways this product violates security‑by‑default expectations under the CRA.
• For each violation, write down a more secure default.

Use this structure in your notes:

• Violation → Secure default

Then compare your answers with the sample solutions below.

Sample solutions (do not peek too early):

• Default shared admin password → Force unique, strong admin password at first login; no shared default credentials.
• Unauthenticated status page with logs → Restrict to authenticated admins; minimise sensitive info exposed.
• Updates disabled by default → Enable security updates by default, or at least strongly prompt and explain the risk.
• New users as Project Manager → Default to lowest necessary role (e.g. basic user) and require explicit elevation.

Step 7 – Minimising Attack Surface and Securing Interfaces

A central CRA expectation is to minimise the attack surface of your software.

In practice, this means:

1. Expose fewer entry points

• Only open network ports that are strictly necessary.
• Avoid debug endpoints or test APIs in production builds.
• Remove unused features or make them opt‑in.

1. Harden all interfaces

• For web APIs: strong authentication, authorisation checks, rate limiting, and input validation.
• For GUIs: role‑based access to admin functions; no hidden “backdoor” menus.
• For CLI/admin interfaces: restrict to secure channels (e.g. SSH with key‑based auth).

1. Secure default network posture

• Use deny‑by‑default firewall rules; explicitly allow only required services.
• Avoid automatically binding services to `0.0.0.0` (all interfaces) when `localhost` would be enough.

1. Handle data securely at all interfaces

• Encrypt sensitive data in transit (TLS) and at rest when appropriate.
• Ensure integrity checks (e.g. message authentication codes, digital signatures) where tampering is a risk.

These design decisions should be captured in your technical documentation to demonstrate CRA compliance.

Step 8 – Code Example: Secure Defaults in a Web API

The following simplified Node.js/Express example illustrates some security‑by‑default and attack surface minimisation ideas:

```javascript

import express from 'express';

import helmet from 'helmet';

import rateLimit from 'express-rate-limit';

import { authenticateJWT, requireRole } from './auth-middleware.js';

const app = express();

// 1. Security headers by default

app.use(helmet());

// 2. Minimal parsing (only JSON, limited size)

app.use(express.json({ limit: '100kb' }));

// 3. Rate limiting on all routes (can be tuned per route)

const limiter = rateLimit({

windowMs: 15 60 1000, // 15 minutes

max: 100, // limit each IP to 100 requests per window

});

app.use(limiter);

// 4. Health check with minimal info, no stack traces

app.get('/health', (req, res) => {

res.status(200).json({ status: 'ok' });

});

// 5. All API routes require authentication by default

app.use('/api', authenticateJWT);

// 6. Admin route requires explicit admin role

app.get('/api/admin/users', requireRole('admin'), async (req, res) => {

const users = await getAllUsers();

res.json(users);

});

// 7. Bind to localhost by default (can be overridden via config)

const PORT = process.env.PORT || 3000;

const HOST = process.env.HOST || '127.0.0.1';

app.listen(PORT, HOST, () => {

console.log(`Server running on http://${HOST}:${PORT}`);

});

```

What this demonstrates:

• Secure defaults: security headers, rate limiting, minimal body size.
• Attack surface reduction: only JSON, minimal `/health` info, localhost binding by default.
• Security‑by‑default: all `/api` routes require authentication; admin routes require explicit roles.

In a CRA context, you would document these choices as part of your secure design and configuration baseline.

Step 9 – Quick Check: Security‑by‑Design vs Security‑by‑Default

Answer this question to test your understanding of the two core principles.

Step 10 – Key Term Review

Flip the cards to reinforce the main concepts from this module.