Drupal cut core minor security support from 12 months to 8 — here's my new upgrade calendar

Drupal just changed the clock on every site I maintain. In PSA-2026-11-02, published on 28 October, the Security Team announced that each Drupal core minor release will get 8 months of overlapping security coverage instead of 12. It's one paragraph on a security page, but it quietly rewrites my upgrade calendar for the next two years.

What actually changes

Since Drupal 8.6 in 2018, every minor (11.3, 11.4 and so on) has been supported for 12 months. Starting in 2027 that drops to 8: six months of bugfix support followed by two months of security-only support. The final minor of each major keeps the longer shape, six months of bugfix plus six months of security. Major versions are untouched: the PSA promises at least four years each.

The dates the PSA spells out are worth copying into a calendar:

Drupal 11.3 (December 2025): supported until December 2026. Drupal 11.4 (June 2026): until April 2027. Drupal 12.0 and 11.5 (scheduled December 2026): until August 2027. Drupal 12.1 and 11.6 (scheduled June 2027): until February 2028.

Note that 11.4 is the odd one out. It gets 10 months rather than 12 because the old schedule is being phased out, so anyone who treated "11.4 gives me until June 2027" as a given has two months less than expected.

Why the Security Team did it

The stated reason is blunt. The PSA says Drupal, like all open source projects, is enduring a "tsunami" of security reports because of AI tooling, and that this is more work than the team can sustain at its current funding. Fewer overlapping supported minors means fewer backports: the PSA estimates a 30% cut in backport work for core security advisories. It also notes better alignment with Symfony upstream releases as a side benefit.

I wrote recently about how the advisory count is climbing, so the logic tracks. Every core SA that must land on three branches instead of two or three costs volunteer hours. I'd rather have a shorter window and faster fixes than a long window where the fixes slow down, which is exactly the risk the PSA names.

What it means for my sites

Practically, "stay on one minor for a year" is no longer a safe default. With 8 months of coverage and a six-month bugfix phase, a site that updates minors once a year will spend part of every cycle on an unsupported branch. The workable policy now is to move to each new minor within roughly two months of release, which is the point where the previous one drops into security-only mode.

For me that means three concrete things. First, put the PSA dates above into the calendar, with the 11.3 end of December 2026 as the first hard stop. Second, make sure the Composer constraints on my projects track ^11 without pinning to a minor, so an update is a composer update away rather than a constraint rewrite. Third, tighten the testing loop, because more frequent minors only work if the upgrade is boring.

The deal Drupal is offering is clear: four-year majors stay, but minors become something you ride, not something you park on. I think that's a fair trade for a team drowning in reports, and it's one more argument for treating core updates as routine maintenance instead of an annual project.