CyberForte
0/32 guides done, see your progress

Home Secure by Design and Default Playbook 22

Playbook 22 of 22 · Secure by Default · Guided Protection

Secure recovery and ownership life cycle

Resets, recoveries and handovers that help the owner, not the intruder.

Guided ProtectionSecure by Default
CyberForte's summary · not ENISA text

In plain words

Password resets, factory resets and selling or handing over a device are all moments when control changes hands. They are also favourite targets for attackers and social engineers.

Decide which recovery and transfer actions you support and who may start them, check identity properly before allowing them, watch and rate-limit those workflows, and make sure a reset or handover really removes the previous owner's access, credentials and secrets.

Picture this: A second-hand device that still lets its first owner log in remotely has not really been handed over. A proper reset wipes the old keys and accounts.

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, 22-secure-recovery-and-ownership-life-cycle.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 recovery and ownership life cycle

Principle

(secure by default)

Provide secure, guided recovery and ownership transfer mechanisms by default. Recovery, reset and transfer processes must be easy for users, operators and administrators to follow, while remaining resistant to abuse, account takeover and social engineering.

Objective

To enable users and administrators to recover access, reset systems or transfer ownership safely.

Checklist

Define supported recovery and transfer actions

  • Identify supported recovery actions such as credential reset, account recovery, secure factory reset and ownership transfer, clearly defining who is allowed to initiate each action and under what conditions

Verify identity before recovery or transfer

  • Require strong identity verification before allowing recovery, reset or ownership transfer actions.

Protect recovery paths from abuse

  • Ensure that recovery mechanisms cannot be used to bypass normal authentication or authorisation controls.
  • Apply monitoring and rate limiting to recovery and reset workflows.

Ensure secure reset and ownership transfer

  • Ensure that factory reset and ownership transfer fully remove previous user access, credentials and secrets.

Provide guided, secure workflows

  • Offer clear recovery and transfer processes that reduce user error

Minimum evidence

  • Recovery and transfer actions are defined: documentation identifies supported recovery, reset and ownership transfer processes.
  • Strong verification is enforced: configuration or test evidence shows that recovery and transfer actions require a verified identity.
  • Abuse protections are applied: configuration, logs or test evidence shows that rate limiting and monitoring of recovery workflows are in place.
  • Secure reset and transfer is verified: test evidence confirms that factory reset and ownership transfer remove prior credentials and access.
  • Guided workflows are available: screenshots, CLI commands or documentation demonstrates that recovery and transfer processes are guided.

Release gate

  • [ ] Supported recovery and ownership transfer actions are defined
  • [ ] Recovery and transfer actions require strong identity verification
  • [ ] Recovery mechanisms cannot bypass normal access controls
  • [ ] Factory reset and ownership transfer fully remove prior access
  • [ ] Clear guidance is provided on recovery and transfer workflows
↑ ↓ to moveEnter to openEsc to close