CyberForte
0/32 guides done, see your progress

Home Secure by Design and Default Playbook 17

Playbook 17 of 22 · Secure by Default · Default Hardening

Secure communication by default

Everything that leaves the box is encrypted and checked, from day one.

Default HardeningSecure by DefaultENISA suggests: early baseline
CyberForte's summary · not ENISA text

In plain words

Data travelling over a network can be read or changed on the way unless it is protected. This playbook says all external communication should be encrypted and authenticated by default, with no plain-text fallback "for convenience".

Use modern protocol versions, switch off weak ciphers, make both ends prove who they are where it matters, and refuse the connection rather than quietly downgrading when something fails. Also design so you can swap algorithms and certificates later, including planning ahead for post-quantum cryptography where your product lives a long time.

Picture this: If the secure connection fails and your device silently falls back to plain HTTP, an attacker only needs to break the secure one to get the easy one.

Your turn

Practical checklist

A short, practical version for small teams, written by CyberForte from the ENISA playbook. The full ENISA checklist, evidence list and release gate are in the original text below. Your ticks are saved only in this browser.

Original text · unchanged

The full ENISA playbook

Source: ENISA Secure by Design and Default Playbooks, 17-secure-communication-by-default.md, European Union Agency for Cybersecurity (ENISA), licensed under CC BY 4.0. Reproduced word for word; only converted from Markdown to this page.

Secure communication by default

Principle

(secure by default)

Enforce secure communication from the start. All external communications must be encrypted and authenticated by default, with no support for insecure or plain-text protocols for convenience.

Objective

Protect data in transit and prevent interception, tampering or impersonation by ensuring that communications are always secure, without relying on user configuration or later hardening.

Checklist

Protect external communications by default

  • Require encrypted communication for all external interfaces from first use.
  • Where data or commands pass through intermediaries, assess whether transport protection alone is sufficient or whether additional end-to-end authenticity, integrity and freshness controls are required.

Disable insecure and plain-text protocols

  • Do not allow unencrypted or weak protocols (e.g. HTTP or Telnet) to be used by default or even as fallbacks.

Authenticate communicating endpoints

  • Ensure that external endpoints authenticate each other where appropriate, for example for device-to-cloud, service-to-service and administrative access.

Enforce secure protocol versions and configurations

  • Use modern, secure protocol versions and configurations by default.
  • Explicitly disable weak ciphers, legacy versions and insecure negotiation modes.

Fail securely on connection errors

  • Ensure that communication failures result in denied connections rather than downgrading to insecure protocols or configurations.

Plan for cryptographic change

  • Design cryptographic mechanisms so that algorithms, keys, certificates and trust anchors can be replaced or migrated without substantially redesigning the product, where feasible.
  • Assess whether the product’s support lifetime, data confidentiality requirements and deployment constraints require preparation for migration to post-quantum cryptography.

Minimum evidence

  • Secure protocols enforced by default: configuration or test evidence shows that encrypted and authenticated communication is required from first connection.
  • Insecure protocols disabled: configuration confirms that plain-text or legacy protocols are not enabled or available.
  • Endpoint authentication in place: configuration or test evidence shows that mutual or appropriate endpoint authentication takes place for external communications.
  • Strong protocol configuration applied: configuration shows that only approved protocol versions and cryptographic settings are enabled.
  • No insecure fallback: test evidence shows that connection attempts fail securely rather than downgrading security.
  • Cryptographic migration note: identification of critical cryptographic mechanisms and how algorithms, keys, certificates and trust anchors are to be updated or replaced.

Release gate

  • [ ] External communications are encrypted and authenticated from first connection
  • [ ] Insecure or plain-text protocols are disabled and unavailable
  • [ ] Only approved secure protocol versions and configurations are enabled
  • [ ] Endpoint authentication enforced where required
  • [ ] Connection failures do not result in insecure fallback
  • [ ] Cryptographic mechanisms can be replaced or migrated where required by the product’s risk assessment and support lifetime.
↑ ↓ to moveEnter to openEsc to close