Debian 11 Bullseye EOL: Action Plan 2024

Debian 11 (Bullseye) End-of-Life Is August 14, 2024 — Your Last-Call Action Plan

Debian 11 (Bullseye), the current stable release, reaches its end of life on August 14, 2024. After that date, the Debian Security Team will no longer release security updates, bug fixes, or patches for Bullseye. This is not an LTS release, and the latest point release in this line is 11.11. If your estate includes any Bullseye systems, read on for a realistic, actionable plan — because a full migration before the deadline is no longer feasible for most organisations.

What Changes on August 14, 2024

When Bullseye reaches EOL, the following support mechanisms stop immediately:

• No more security advisories or patch releases from the Debian Security Team.
• No more updated packages for Bullseye in the official repositories (including security.debian.org).
• No vendor SLA or response commitment of any kind — the project considers the release retired.

Your systems will continue to run, but they will accumulate unpatched vulnerabilities. Regulators and auditors view unsupported operating systems as a material risk, and insurers may require documented risk acceptance or remediation plans.

Why a Full Migration Is Off the Table (for Most)

A clean migration to Debian 12 (Bookworm) involves re-provisioning, testing application compatibility, and validating configurations across potentially hundreds of hosts. Three months is tight, especially for estates that cannot tolerate downtime or that run legacy software.

Instead, use the time before August 14 to prepare defensively: identify all affected systems, isolate them, and line up a support path that covers day one after EOL.

Week-by-Week Action Checklist (12 Weeks to Go)

Weeks 1–2: Complete Inventory

• Run lsb_release -a (or cat /etc/os-release) on every server, container, and VM to confirm which are Bullseye.
• Cross-reference with CMDB or configuration management data.
• Document the business owner, criticality, and dependencies for each Bullseye system.
• Tag or label these systems in your monitoring and ticketing tools.

Weeks 3–4: Risk Assessment & Hardening

• Rank each system: critical (internet-facing, data-sensitive) vs. internal-only.
• For critical systems: review firewall rules, limit egress, and enable logging.
• Isolate where possible: move to a restricted VLAN, disable SSH password auth, enable fail2ban.
• Document compensating controls (e.g. “system is behind WAF and has no direct internet access”).

Weeks 5–6: Document for Auditors & Insurers

• Create a risk acceptance letter template. For each Bullseye host, state why it cannot be migrated now, describe compensating controls, and get sign-off from the system owner.
• Review your cyber insurance policy for any EOL requirement. If missing, update your risk register.
• Prepare a timeline for eventual migration or decommissioning (even if that timeline is “in next planning cycle”).

Weeks 7–8: Test Migration Path (Optional but Recommended)

• For a small, non-critical Bullseye system, attempt an in-place upgrade to Debian 12 in a staging environment.
• Document any blockers (e.g. unsupported libraries, custom kernel modules).
• If in-place upgrade is not possible, script a fresh installation and data migration.

Weeks 9–10: Secure Extended Support

• If migration cannot be completed in time, evaluate a contractual support provider that covers Bullseye post-EOL. Options include commercial third-party support or an LTS subscription (Debian LTS is available for some versions, but Bullseye is not an LTS release).
• Ensure the support contract begins on August 14, 2024 — do not let any day gap exist.
• Submit any required procurement requests now; approval cycles can take weeks.

Weeks 11–12: Final Lockdown & Cutover

• Apply all remaining Bullseye security updates. After August 14, they will not be available without a support contract.
• Run a final vulnerability scan of Bullseye systems and baseline your exposure.
• Update monitoring rules to alert if any Bullseye system is not covered by a post-EOL support plan.
• Ensure your DR/BCP documentation lists Bullseye systems as unsupported effective August 14.

What If I Miss the Deadline?

If Bullseye reaches EOL and you have no support contract in place:

• Your systems are immediately unsupported. New CVEs will not be addressed.
• You must accept the risk or take those systems offline until a plan is in place.
• Do not leave Bullseye connected to a production network without a documented risk acceptance and compensating controls.

How Third-Party Support Can Help

If migration is not feasible before August 14, a third-party maintenance provider can supply backported security patches and technical support for Bullseye systems beyond the vendor’s EOL date. This buys you time to plan and execute a controlled migration on your own schedule, while keeping auditors and insurers satisfied. Contact us to discuss coverage options for Debian 11.

Bottom line: Act now on inventory, isolation, and documentation. A full migration in three months is unlikely, but a defensible posture plus a support contract is achievable by August 14.