CyberForte
0/32 guides done, see your progress

Home Secure by Design and Default Playbook 16

Playbook 16 of 22 · Secure by Default · Default Hardening

Restrictive initial access

No "admin/admin". Every unit starts locked, with its own key.

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

In plain words

The first minutes after a device is plugged in are risky. If every unit ships with the same username and password, anyone who reads the manual can get in. This playbook says: ship in the most locked-down state possible.

Give each device or installation its own unique credentials, make people set up proper access before they can do anything sensitive, start with minimal permissions, and protect the first-boot, onboarding and recovery screens so they are not an easy way in.

Picture this: A sticker with a unique password on each device, plus a forced password change at first login, beats a shared default every time.

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, 16-restrictive-initial-access.md, European Union Agency for Cybersecurity (ENISA), licensed under CC BY 4.0. Reproduced word for word; only converted from Markdown to this page.

Restrictive initial access

Principle

(secure by default)

Ship systems in the most restrictive access state possible. Eliminate shared or default credentials and require a secure access set-up before any privileged or sensitive operations are allowed.

Objective

To prevent immediate compromise after deployment by ensuring that attackers cannot gain access through default or weak initial access.

Checklist

Eliminate shared default credentials

  • Do not ship products with universal usernames or passwords (e.g. ‘admin/admin’ or ‘root/root’).

Require unique credentials for each device or instance

  • Ensure that each device or instance has unique credentials generated at manufacture, provisioning or first boot.

Enforce a secure initial set-up

  • Require a credential change, key provisioning or account creation before allowing privileged or sensitive access.

Restrict initial permissions

  • Grant the minimum permissions required for initial operation.
  • Avoid granting full administrative access by default.

Protect initial access paths

  • Ensure that first-boot, onboarding and recovery interfaces are authenticated and not unnecessarily exposed.

Minimum evidence

  • No default credentials shipped: build configuration or documentation confirms that no shared or hard-coded credentials exist.
  • Unique credentials enforced: provisioning records, configuration or device inventory shows per-device or per-instance credentials.
  • Secure set-up required: configuration or test evidence shows credential change or secure set-up is mandatory before privileged or sensitive access.
  • Initial permissions restricted: access model or configuration shows limited permissions at first use.
  • Initial access paths controlled: configuration or test evidence shows that onboarding and recovery interfaces are protected.

Release gate

  • [ ] No shared or default credentials present in production builds
  • [ ] Unique credentials generated for each device or instance
  • [ ] Secure set-up enforced before privileged or sensitive access
  • [ ] Initial permissions are restrictive by default
  • [ ] Initial access and onboarding paths are protected and reviewed
↑ ↓ to moveEnter to openEsc to close