Eight months: Drupal shortens security support, and your site can't wait a year anymore

I'm migrating several sites from Drupal 10 to Drupal 11 these days. None of them is particularly complicated, but they all take their time. And right in the middle of that, I come across PSA-2026-11-02, where the Drupal Security Team announces it's cutting the support window for each minor version.

Put like that, it might sound like just another technical change, the kind only people following the issue queue care about. But it directly affects how long you can leave a site untouched before you run out of security patches, and that time has just dropped quite a bit.

From twelve months to eight

Since Drupal 8.6, back in 2018, every core minor version got 12 months of security support. With a new minor coming out every six months, that gave you half a year to move from one to the next. Comfortable. So comfortable that a lot of people got used to updating once a year, or whenever they remembered.

Starting in 2027, that becomes 8 months: six of bug fixes and two more of security-only support. The schedule looks like this:

If you do the math, it's pretty simple. When a new minor comes out, the previous one only has two months left. Two months to test, update and deploy. If you haven't done it by then, you're out of support.

What doesn't change is the commitment to major versions: each one still gets at least four years of support. Drupal 11 runs until December 2028 and Drupal 12 until December 2030. But within each major, the pace is now much more demanding.

Why they're doing it

The reason the Security Team gives is AI. They literally talk about a "tsunami" of security reports generated with AI tools, which they can't absorb with their current funding. Every supported version is one more branch every fix has to be backported to, and shortening the window saves them, by their own estimate, 30% of that work. As a bonus, the schedule lines up better with Symfony's.

The announcement itself acknowledges the risk for those of us who run sites: security fixes may take longer to come out, right when attackers are also using LLMs to find vulnerabilities.

This isn't just a Drupal thing. A few days ago I wrote about how every Wednesday has turned into a small Drupalgeddon (in Spanish), and the same is happening with PHP, the Linux kernel and pretty much any software with a meaningful attack surface. This PSA is the other side of that coin. So many vulnerabilities are being found at once that security teams have to choose what they can maintain, and the answer is: fewer versions, for less time.

And Drupal 10 ends on December 9

As if that weren't enough, Drupal 10 reaches end of life on December 9, 2026. After that there won't be any more releases, security ones included. Drupal 12 comes out that same week, and it requires PHP 8.5 at minimum.

If you have a site on Drupal 10, the jump you need to make now is to Drupal 11, which is supported until late 2028. And I'm telling you this from what I'm doing right now: it's not a hard migration, nothing like getting off Drupal 7 was. But it takes time, and how much depends almost entirely on how the site has been maintained so far.

What's taking me the most time isn't core. It's everything around it:

• Custom code still using APIs that have been deprecated for two or three versions, and that nobody updated because "it worked".
• Contributed modules stuck on an old version that now need to jump several versions at once, with their config changes and update hooks.
• The odd module with no Drupal 11 compatible release, or that's simply abandoned, where you have to decide whether to patch it, replace it or rewrite it.
• Patches in composer.json that no longer apply against the new version.
• The PHP upgrade on the server, which on some hosting providers isn't as straightforward as it should be.

Upgrade Status and Drupal Rector help a lot, but they don't work miracles. A site that's been kept up to date arrives at the migration with half the work already done. One that's gone two years without being touched arrives with everything piled up.

A website needs maintenance too

I always say a website is almost a living thing. If you don't give it a bit of care on a regular basis, it ends up causing problems. Although maybe the fairer comparison is with any kind of infrastructure: nobody expects a road or a railway line to last twenty years without anyone checking on it.

If you live in Spain, you'll know what I mean, because we've seen it with trains this year. Between the accidents in January at Adamuz and on the Rodalies commuter network in Catalonia, and the delays that have become routine on many lines, the maintenance of the rail network has been part of every conversation. The investigations will determine the specific causes, but there's one figure that's worth thinking about: according to Eurostat, in 2024 Spain spent 15.8% of its railway investment on maintenance, the lowest share since 2016.

I don't want to make light of something where people died, and a website going down can't be compared to that. But the underlying mechanism is similar. Maintenance is invisible and never makes it into a photo. Cutting back on it for a while has no visible consequences, and that's exactly why it's so tempting. The problem is that the deterioration builds up quietly, and by the time you finally notice it, fixing it costs much more than maintaining it would have.

The same thing happens with a website, on a different scale. The less you invest in maintenance, the more likely you are to have a serious problem one day: a vulnerability you didn't patch because you were out of support, an update you have to rush that breaks half the site, or a migration that turns into a months-long project.

What should go into the budget

If you have a Drupal site, or you're thinking about building one, maintenance has to be in the budget from day one. Not as something you do "if there's money left over", but as a fixed cost, just like hosting.

With the new schedule, that maintenance should cover at least:

• Core updates as soon as they're released, and the move to the next minor version within that two-month window. Twice a year, no excuses.
• Contributed module updates, which also get security advisories every week and which, if you let them fall behind, are the ones that hurt the most later.
• Keeping custom code up to date, removing deprecations as they appear. That's what makes the jump to the next major version a matter of days rather than months.
• The server: PHP version, database and operating system. There's not much point in having Drupal up to date on a PHP version that's out of support.

None of this is particularly expensive if it's done regularly. What's expensive is doing it all at once every three years, usually in a rush because support is ending or because a critical vulnerability just came out.

If someone wonders whether it's really worth paying for monthly maintenance on a site that's "already done", I'd flip the question around: how much would it cost you to have the site down for a week, or to rebuild it because it's fallen so far behind that updating it isn't worth it anymore?

And if your site is still on Drupal 10, there's not much left to think about. You've got five weeks.