Running a CMS Past End of Support: The Risk Playbook

Running a CMS Past End of Support: The Risk Playbook

If your CMS loses vendor security patches before your replatform is done, this guide is for you. It covers compensating controls, audit exposure, paid bridge options, and how to turn accidental drift into a documented, owned decision.

This is not a migration-timing article. It is an operating guide for the period between the day your vendor stops patching and the day your replacement goes live. That period might be three months or eighteen — and the difference between "we're managing the risk" and "we forgot" is entirely a function of how you handle it.

This guide is published by ClonePartner, a data migration services provider. Our commercial interest is transparent — we want you to understand the full scope so you can make an informed decision, whether or not you work with us.

---

Which CMS deadlines are we talking about?

Several major content management platforms hit end of vendor support within weeks of each other in late 2026:

Platform	Support End Date	What stops	Extended support available?
Drupal 10	December 9, 2026	Security advisories, bug fixes, official support	No vendor-backed bridge
Umbraco 13	December 14, 2026	Security patches, updates	Yes — 6, 12, or 24-month XLTS via private NuGet feed
Kentico Xperience 13	December 31, 2026	Hotfixes, security patches, technical support	No — no patches at any price
Sitecore XP 10.0 / 10.1	December 31, 2026	All support, including paid Extended Support	No — paid ES ends Dec 31, 2026 for 10.0/10.1

In every case, the software keeps running. The risk is not that the lights go out. The risk is that newly discovered vulnerabilities go unpatched permanently, and the people responsible for your security posture — auditors, insurers, enterprise customers — know it.

For a broader view of 2026 end-of-life events across the enterprise stack, see our Software End of Life 2026 calendar.

---

What actually changes when vendor patches stop?

End of support is a security boundary, not a shutdown. Your site loads, editors log in, forms submit. Nothing visibly breaks on day one. That is precisely why teams underestimate the exposure.

Three concrete things change:

New CVEs go unpatched — permanently. After Drupal 10's December 9, 2026 deadline, the Drupal Security Team will not issue patches for core or contributed modules. Any vulnerability discovered after that date has no official fix — zero-day vulnerabilities become permanent exposures unless you engineer an infrastructure-level workaround. The same applies to Kentico Xperience 13 and Umbraco 13 after their respective dates.

The dependency chain rots simultaneously. A CMS does not operate in isolation. Kentico Xperience 13 is built on Microsoft's .NET 6 framework, which reached end of support in November 2024 — meaning Kentico 13 operators are already running a doubly-expired stack. Upgrading the underlying server OS or runtime often breaks the legacy CMS; keeping the legacy CMS pinned forces you to maintain outdated, vulnerable infrastructure alongside it. This compounding effect accelerates the risk exposure materially.

The vendor disclaims liability. After December 31, 2026, any damages, losses, or security incidents on Kentico Xperience 13 are explicitly the operator's responsibility — including data breaches, business interruptions, and compliance violations. The contractor talent pool thins in parallel as agencies shift training budgets to successor platforms, making specialized support harder to find and more expensive when you need it most.

When the right answer is to take the CMS offline entirely. For low-traffic or internal-only sites — intranets, staging environments, archival content — the operationally correct answer may be to disable public internet access entirely and run the CMS on an internal network. No internet-facing exposure eliminates most of the attack surface without requiring any other compensating control. If the CMS is not serving revenue-critical traffic, evaluate this option first before investing in WAF rules and access controls you will need to maintain for an extended period. The compensating-controls framework below applies to internet-facing, revenue-critical deployments where shutdown is not practical.

---

How auditors, insurers, and enterprise customers will ask about this

Running unsupported software changes three external conversations that most teams are not prepared for.

Audit and compliance

NIST SP 800-53 control SA-22 (Unsupported System Components) requires organizations to either replace unsupported components or provide alternative sources for continued support. NIST 800-171 carries equivalent language. PCI DSS allows compensating controls for unsupported software but requires documented justification, stronger monitoring, network isolation, and allowlisting of approved processes. CIS Control 2.2 requires that unsupported software be explicitly tagged as unsupported in your asset inventory — leaving it ambiguous is itself a finding.

An auditor will ask: "Is this component supported by the vendor?" When the answer is no, the follow-up is: "Where is the documented risk acceptance, who owns it, and what compensating controls are in place?" If you cannot answer all three, you have a finding. When auditors see a tracked risk with active compensating controls and a credible exit plan, findings are typically downgraded from critical failures to observations.

The NIST and vendor documents referenced in this guide are publicly available at NIST SP 800-53, the Drupal security policy, and each vendor's published product lifecycle page.

Cyber insurance

Across recent renewal cycles, carriers have been writing end-of-life and unpatched-system exclusions directly into commercial cyber policies. Coalition's 2024 Cyber Threat Index and published underwriting guidelines explicitly name unsupported software as a material underwriting factor. Beazley and Chubb have both issued guidance noting that claims originating from known-unpatched vulnerabilities in EoL software may be denied under policy exclusions for "failure to maintain security controls."

The plain meaning: if a loss traces back to software that no longer receives vendor support, coverage may not apply — even if every other control in your environment is exemplary. Some carriers apply coinsurance provisions that shift an increasing share of the loss onto the policyholder the longer a system remains out of compliance. Your policy renewal date may be the more urgent deadline. Read your application questionnaire line by line; a "yes" next to unsupported software that you cannot substantiate with compensating-control documentation is a misrepresentation risk that can void coverage entirely.

Enterprise customers and procurement

If you sell to enterprises, vendor security questionnaires increasingly ask whether your production stack includes end-of-life components. A documented compensating-controls plan with a named owner and review cadence is the difference between a clean vendor approval and a failed security review. Expect questions like:

• What exact version is running, and when did support end?
• Is any vendor or external provider still supplying security fixes?
• Is the CMS internet-facing, and is it inventoried as unsupported?
• Do all remote and administrative paths require MFA?
• When did you last test recovery, and who owns the exception?

If you cannot answer those cleanly, the problem is no longer just technical debt. It is governance debt.

---

Compensating controls: what they cover and what they don't

A compensating control is an alternative security measure implemented when a primary security requirement — in this case, vendor patching — cannot be met. Per NIST SP 800-53A, compensating controls must achieve an equivalent security outcome and be validated through documented risk assessment. The following controls are ordered by impact-to-effort ratio for an internet-facing CMS.

WAF effectiveness: what it blocks and what it doesn't

A web application firewall in front of the CMS is the highest-leverage single control available. Commercial WAFs (Cloudflare, AWS WAF, Azure Front Door, Fastly) and open-source options (ModSecurity with the OWASP Core Rule Set) can block known exploit patterns without touching application code.

Vulnerability class	WAF coverage	Notes
SQL injection (network-layer)	Reliable	Core Rule Set has broad signatures
Cross-site scripting (reflected)	Reliable	Well-covered by CRS rules
Remote code execution via known CVE	Partial	Depends on virtual patch availability; typically published within hours of high-profile CVE disclosure
Authentication bypass (credential stuffing)	Partial	Rate limiting + IP reputation helps; not a complete block
Logic flaws in admin interface	None	WAF cannot parse application business logic
Authenticated session abuse	None	Attacker is already past the perimeter
Background job / cron vulnerabilities	None	Not exposed over HTTP
Server-side request forgery (SSRF)	Partial	Depends on WAF configuration and egress filtering

Because you are no longer changing core application code, you can run the WAF in a highly restrictive mode. Deploy in detection mode first, tune against real traffic, then enforce. Cover public delivery paths, login and admin paths, and any exposed APIs. If a WAF rule breaks a legacy feature, investigate whether that feature is operationally necessary before bypassing the rule.

Tighten administrative access

The administrative backend is the highest-value target. Most CMS compromises occur via login paths (/admin, /sitecore, /umbraco) using stolen or brute-forced credentials.

• Enforce MFA on every admin and editor account. If the CMS does not natively support MFA, place an authentication proxy in front of the admin path. Okta, Cloudflare Access, and Azure AD Application Proxy all support this without modifying CMS code.
• Restrict admin interface by IP allowlist or VPN. An admin panel unreachable from the public internet cannot be exploited from it. For distributed teams, implement Zero Trust Network Access (ZTNA) requiring strong identity verification before the login screen is visible.
• Prune dormant accounts. Every inactive editor account with a reused password is a credential-stuffing target.
• Apply least privilege. Editors should not hold deployment or plugin-install permissions. Use dedicated admin identities separate from daily-use accounts.

Disable unused modules to reduce attack surface

Every active plugin, module, and integration is a potential entry point carrying its own dependency tree.

Discovery methodology:

• Drupal: Run drush pm:list --status=enabled to enumerate all active modules. Cross-reference against content types and active features in production.
• Kentico Xperience 13: Navigate to Admin > Modules; review enabled status and last-used timestamps.
• Umbraco 13: Inspect appsettings.json and the App_Plugins directory; review the package manifest for installed components.
• All platforms: Run a traffic analysis against the CMS over 30 days to identify endpoints that receive zero real traffic. Modules serving those endpoints are candidates for removal.

Once identified, disable and delete unused components from the server filesystem rather than simply toggling them off in the UI. A disabled plugin that still exists on disk can be re-enabled by an attacker with file-system access. This is the cheapest control on the list and one of the most effective in terms of surface reduction.

Dependency and CVE monitoring

Without vendor bulletins, you must actively monitor for newly disclosed vulnerabilities.

Subscribe to NVD feeds for every component in the stack: the CMS, its runtime (.NET 6, PHP 8.x), framework dependencies (Symfony, ASP.NET Core), and the database engine. Tools like Dependabot, Trivy, and Snyk can automate CVE matching against your installed package manifest. Add CISA's Known Exploited Vulnerabilities (KEV) catalog as a priority signal — it flags flaws already being weaponized in the wild.

The goal is not necessarily to patch (you often cannot). The goal is awareness with response capability: knowing when a new vulnerability is disclosed so you can evaluate whether existing WAF rules or network controls already mitigate it, and escalate to the "halt or decommission" decision if they do not.

What a critical unmitigated CVE should trigger: If a CVE is disclosed against your CMS version, rated CVSS ≥ 9.0, with a public exploit, and your WAF cannot produce a virtual patch within 48–72 hours, that is an exit criterion for the accepted risk. The system should be taken offline or access restricted to internal networks until migration is complete or the threat is otherwise contained.

Tested restore path

A backup you have never restored is a hypothesis, not a control.

Define and test your recovery time objective (RTO) — the maximum time to restore from a known-good state — and your recovery point objective (RPO) — the maximum data loss acceptable. Test the full restore process end-to-end (database, media assets, configuration, environment secrets) at least quarterly under realistic conditions. Document the test results with timestamps.

Network segmentation

Isolate the CMS from internal systems. If the CMS is compromised, segmentation limits lateral movement. The CMS application server should not have direct network paths to internal LDAP directories, ERP systems, payment infrastructure, or other services. NCSC guidance on legacy system management recommends minimizing services an obsolete server offers and restricting the routes by which malicious data can reach adjacent systems.

Residual risk after layered controls

No set of compensating controls eliminates all exposure. The table below characterizes residual risk after implementing WAF + MFA + module pruning + segmentation:

Threat vector	Residual risk level	Remaining exposure
Unauthenticated remote exploit (known CVE)	Low–Medium	Depends on WAF virtual patch coverage
Credential stuffing against admin	Low	MFA eliminates most automated attacks
Zero-day exploit (unknown CVE)	High	No compensating control covers unknown vulnerabilities
Insider or authenticated attacker	Medium	Least privilege reduces blast radius; does not eliminate
Supply chain compromise (dependency)	Medium–High	Monitoring provides awareness; cannot block undetected
Infrastructure-layer vulnerability (.NET 6, OS)	Medium	Segmentation limits impact; patch gap remains

An honest residual risk assessment shows that WAF + MFA + segmentation meaningfully reduces exposure to known-CVE exploitation and credential attacks. It does not meaningfully reduce exposure to zero-days or supply chain compromises. Document this honestly in your risk register.

---

Does your CMS vendor sell extended support?

Not all vendors offer a paid bridge past end of support. Assuming one exists is a common planning error.

Umbraco: yes, with specifics. Umbraco offers Extended Long-Term Support (XLTS) in 6-, 12-, or 24-month terms starting from December 14, 2026. Coverage requires continuous subscription — gaps are not permitted and restart eligibility is unclear. Updates are delivered via a private NuGet feed, which means your build pipeline must be configured to authenticate against Umbraco's XLTS feed rather than the public NuGet registry. For audit purposes, the XLTS contract and feed access constitute vendor-backed evidence that security patches are still being applied — directly answering the SA-22 "alternative source of support" requirement. Contact Umbraco directly for current XLTS pricing; it scales by number of active sites.

Kentico: no, categorically. Kentico's published product lifecycle is unambiguous: after December 31, 2026, no hotfixes, security patches, or technical support are available at any price. Kentico does not offer extended support tiers for Xperience 13. The only vendor-endorsed forward path is migrating to Xperience by Kentico, which is a replatform, not an upgrade.

Sitecore: tiered and changing. Sitecore restructured its Extended Support model effective June 1, 2026, making production incident support and security updates paid for all versions in Extended Support. XP 10.0 and 10.1 exit Extended Support entirely on December 31, 2026, after which no patches are available at any price. XP 10.2 and above retain paid Extended Support beyond that date, but the per-year cost and the changed model economics mean the effective price increased mid-cycle. If you are on 10.0 or 10.1, the Sitecore calendar and the Kentico calendar are identical in effect.

Drupal 10: no vendor-backed bridge. Prior to Drupal 8, commercial vendors offered paid support packages for end-of-life Drupal versions. That model collapsed because Drupal 8+ is built on Symfony — a vendor cannot backport security patches without also patching Symfony, which is maintained by a separate open-source project. The practical target is completing an upgrade to Drupal 11 before December 9, 2026. Some specialized Drupal agencies offer informal paid support arrangements, but these are not structured products and provide no audit-ready documentation equivalent to the XLTS model.

If your platform offers paid extended support, purchase it. An XLTS or paid extended-support contract gives you audit-ready evidence that a vendor is actively patching the software — directly satisfying NIST SA-22's "alternative source of continued support" provision and answering the insurer's underwriting question with documentation rather than assertions.

---

Decision framework: which controls to prioritize given your situation

Not every organization has the same risk profile. Use this framework to prioritize:

If your replatform runway is under 3 months:

• Implement WAF + MFA immediately — these two controls deliver the highest risk reduction per hour of effort.
• Do not invest in extensive module audits or segmentation redesign; the time cost exceeds the benefit given the short window.
• Focus engineering capacity on migration, not on fortifying a system you are about to retire.
• Purchase XLTS if available and if the cost is less than one sprint of engineering time.

If your replatform runway is 3–9 months:

• Implement the full compensating controls stack: WAF, MFA, module pruning, CVE monitoring, tested backups, segmentation.
• Document formal risk acceptance with a 90-day review cadence.
• Evaluate paid extended support; for Umbraco XLTS, the 6-month term maps cleanly to this window.
• Begin decoupling work in parallel (see below).

If your replatform runway exceeds 9 months:

• All of the above, plus: evaluate whether taking the CMS offline or restricting it to internal access is more practical than maintaining an increasingly costly compensating-controls posture.
• The dependency stack (runtime, OS, database) will also require attention — a CMS running on Windows Server 2016 and .NET 6 is accumulating infrastructure-layer CVEs independently of the CMS itself.
• Re-evaluate paid extended support annually; the longer the runway, the more the XLTS or equivalent cost approaches replatform cost.

If the CMS is internal-only or low-traffic:

• Seriously evaluate disabling public internet access. An intranet-only CMS with no internet-facing surface has a fundamentally different risk profile than a public-facing site.
• This option is underused because it is operationally inconvenient, not because it is technically inferior.

---

What to decouple first when the destination CMS is undecided

Teams frequently delay everything because the destination platform has not been selected. The destination decision is real, but it should not freeze parallel workstreams. The following assets can be decoupled regardless of which successor platform you choose:

1. Edge delivery, TLS, CDN, redirects, and media delivery. Move the internet edge first. This lets you add WAF rules, update TLS configuration, and reconfigure redirects without touching the CMS on every iteration.
2. Authentication and admin access. Centralize identity management (Okta, Azure AD, Google Workspace) and enforce MFA at the identity layer rather than the CMS layer.
3. Content and media assets. Export structured content — pages, taxonomy, metadata, media references — into a platform-neutral format (JSON, well-structured CSV, or a headless API layer). Every successor platform needs this data; getting it clean and portable now shortens the actual migration.
4. Integrations, forms, and webhooks. Document every integration's contract surface: API endpoints, webhook payloads, data schemas. Rebuild any integration that runs through proprietary CMS plugins against a stable API you control.
5. Search and personalization data. Move search indexes and behavioral data into a standalone service (Algolia, Elastic, Azure Search). This reduces load on the legacy CMS and creates a reusable service for the replacement.
6. Workflow, preview, and behavior-heavy features last. These are the most destination-specific and destination-dependent. Locking them down early tends to constrain the platform selection before the team is ready to commit.

Decoupling is not the migration. It is preparation that makes the migration shorter, lower-risk, and less dependent on the legacy CMS remaining stable.

---

How to document the accepted risk

Running unsupported software is sometimes the operationally correct short-term decision. The failure mode is not the decision — it is making the decision implicitly, with no owner, no review date, and no evidence trail.

Per NIST SP 800-53A assessment guidance, failure to document the control rationale and evidence of effectiveness constitutes a control deficiency independent of whether the control itself is functioning.

A proper risk acceptance record must include:

• The specific component and version running unsupported (e.g., "Kentico Xperience 13.0.131, EOL December 31, 2026; running on .NET 6, EOL November 2024").
• The named risk owner — an individual with the authority to accept the risk and the accountability if the exposure materializes. "The security team" is not an owner.
• The compensating controls in place, with evidence that each is active: WAF configuration exports with virtual patch rule list, MFA enrollment reports, access-control audit logs, backup test results with timestamps.
• The residual risk after compensating controls — use the residual risk table above as a template. Be honest about zero-day and supply-chain exposure.
• A hard review date — a specific calendar date, no more than 90 days forward, at which the risk owner re-evaluates whether controls are still adequate and the migration timeline has moved.
• An exit criterion — the specific condition under which the accepted risk is no longer acceptable and the system must be taken offline or access restricted. Example: "A CVSS ≥ 9.0 CVE is disclosed against this CMS version with a public exploit, and no WAF virtual patch is available within 72 hours."

Put this in your risk register — a system of record that auditors can query — not in a slide deck, which is a presentation artifact.

---

The two clocks

The timelines in this guide describe operating an unsupported CMS — maintaining safety while executing a migration. They do not describe the replatform itself, which involves selecting a successor, rebuilding templates and integrations, migrating content, and training editors.

These two tracks run in parallel, not sequentially. Compensating controls are not a reason to delay migration planning; they are what makes the delay manageable.

The data migration — moving content, media, and structured data from source to destination — is what ClonePartner handles. That engagement is scoped separately from replatform work.

Typical migration durations, based on project data:

• 1–500 documents: 1–2 days
• 500–5,000 documents: 3–7 days
• 5,000+ documents: Custom engagement, typically an initial bulk migration followed by delta syncs (7–13+ business days)

We recommend beginning migration scoping 3–4 months before your internal go-live deadline. Data that has already been cleaned and structured through the decoupling process described above migrates significantly faster.

We price migrations at a fixed rate per project, starting at $500. Every project includes a dedicated migration engineer and unlimited sample migrations until the output data is correct.

Compensating controls degrade over time. Eventually, the underlying infrastructure becomes too old to maintain safely, or a vulnerability emerges that a WAF cannot contain. The framework in this guide makes the gap period survivable — but it is not indefinite. Secure the perimeter, document the risk formally, make it a decision rather than a drift, and plan the exit before the controls stop holding.