What is the difference between secure-by-design requirements and resilience planning for critical infrastructure?

Secure-by-design requirements aim to prevent or reduce vulnerabilities before systems enter production, through stronger development standards, testing, and supply chain expectations. Resilience planning assumes incidents can still happen and focuses on continuity, recovery, exercising, and coordinated response. Both are necessary, but they solve different problems: one lowers exposure, the other limits impact when defences fail.

Why the distinction matters in critical infrastructure

Secure-by-design requirements and resilience planning address different failure modes. Secure-by-design tries to keep dangerous weaknesses out of the environment in the first place, while resilience planning assumes some failures will still occur and prepares the operator to keep essential services running, recover safely, and coordinate response. In critical infrastructure, you need both because prevention alone cannot absorb every outage, exploit, or supply-chain failure.

The practical difference is where the control objective sits. Secure-by-design changes the product or system before deployment, through stronger engineering standards, secure defaults, testing, and supplier expectations. Resilience planning changes the operating model around the system, including continuity procedures, backup dependencies, restoration sequencing, and exercises that prove the organisation can respond under stress.

That split is why these two ideas are complementary rather than interchangeable. A system may be built to a high security standard and still need CISA Secure by Design expectations for safer defaults, and it may still require DORA-style operational resilience capabilities for testing, recovery, and third-party dependency management.

Where the distinction becomes important for practitioners is in deciding what success looks like. Secure-by-design success is fewer exploitable weaknesses, less exposure at release, and less reliance on compensating controls. Resilience success is the ability to sustain the service when a control fails, including failover, manual fallback, restoration, and coordinated communication with operators and regulators.

How the two approaches differ in practice

Secure-by-design is preventative. It is aimed at architecture, development, procurement, and release decisions that reduce the chance of a material weakness entering production. In critical infrastructure, that often includes secure configuration baselines, patchable components, authenticated management paths, stronger supplier assurance, and limits on exposed interfaces.

Resilience planning is operational and event-driven. It assumes compromise, outage, or corruption can still happen, so it focuses on continuity of essential functions, recovery objectives, backup integrity, incident exercises, and coordination across technical, operational, and leadership teams. The goal is not to make incidents impossible, but to keep them from becoming systemic service failures.

For critical services, the difference also affects measurement. Secure-by-design is judged by release quality, vulnerability reduction, and how much risk is removed before go-live. Resilience planning is judged by recovery time, restoration accuracy, exercise performance, and whether operators can maintain critical functions when primary systems or suppliers fail.

Security and resilience standards often intersect but do not replace each other. A product can be secure at design time yet brittle in operation, especially if there are single points of failure, weak backups, or poor restoration procedures. Conversely, a highly resilient operating model does not excuse a weak design that repeatedly introduces preventable exposure.

Risk and Threat Considerations

Critical infrastructure is exposed to both exploit risk and continuity risk. A design weakness can create the initial compromise path, while a resilience gap can turn a contained incident into prolonged service disruption, unsafe manual workarounds, or cascading dependency failures across suppliers and sectors.

Failure mechanism: Attackers, operational faults, or supplier failures exploit insecure defaults, weak hardening, fragile dependencies, or untested recovery paths. If the organisation treats prevention and recovery as substitutes, it ends up with systems that are either easier to compromise or harder to restore.

Impact: The result can be service downtime, loss of trust, unsafe operational modes, delayed restoration, and broader systemic disruption. In critical infrastructure, that matters because the harm is not limited to the asset owner, it can spread to customers, downstream operators, and public services.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the technical controls, while EU Cyber Resilience Act, DORA and NIS2 define the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 4 — Secure Configuration of Enterprise Assets and Software	Secure-by-design depends on secure defaults and hardened configuration before deployment.
	CIS 17 — Incident Response Management	Resilience planning requires coordinated response and recovery when incidents occur.
Recommendation — Apply CIS 4 to standardize hardened baselines before systems enter production. Use CIS 17 to define and exercise coordinated incident response and recovery steps.
NIST CSF 2.0	PR.DS — Data Security	Design-time protection and recovery both depend on protecting critical data and restoration assets.
	RS.RP — Response Planning	Resilience planning is materially about preparing and exercising response actions for critical services.
	RC.RP — Recovery Planning	The resilience side of the question directly concerns restoring essential functions after failure.
Recommendation — Protect critical data and recovery assets so outages or compromise do not prevent restoration. Develop and exercise response plans that sustain critical services during disruption. Define and test recovery plans that restore critical functions within required timeframes.
EU Cyber Resilience Act	Article 13 — Essential Cybersecurity Requirements	The EU CRA captures secure-by-design expectations for products with digital elements.
Recommendation — Build products to meet essential cybersecurity requirements before release.
DORA	Article 11 — Digital Operational Resilience Testing	Critical-infrastructure resilience depends on exercising response and recovery, not assuming they work.
Recommendation — Test operational resilience regularly so recovery capabilities are proven under realistic conditions.
NIS2	Article 21 — Cybersecurity Risk-Management Measures	NIS2 requires both preventive controls and resilience-oriented measures for essential entities.
Recommendation — Implement preventive controls and resilience measures together for essential services.

Practitioner Guidance

What to prioritise: Treat secure-by-design as the engineering and procurement gate, and resilience planning as the operating requirement. If a control only reduces likelihood, verify the recovery path as well; if it only improves recovery, verify the design still removes obvious exposure.

What to verify: Ask whether the system has been tested under realistic failure conditions, not just reviewed on paper. In practice, the most common mistake is assuming that hardened architecture will cover for missing recovery procedures, or that backups and runbooks can compensate for preventable design weaknesses.

What good looks like: The organisation can show both lower release-time exposure and a working path to continue or restore critical services when the primary control fails. That usually means secure defaults, supplier expectations, exercised incident response, and recovery steps that have been validated under time pressure.

Practitioner takeaway: Secure-by-design reduces the number of incidents you must survive, while resilience planning determines how much damage remains when one still happens, and critical infrastructure needs both to be credible.