In short and in plain language
Many add-ons in your shop need a licence. When it runs out, the add-on usually keeps working. But it no longer gets updates.
That is a risk. Without updates, gaps in an add-on stay open.
The article shows how to keep track of the dates. You keep a list of all add-ons with the end date of each licence.
We keep this list for you. We report each date before it runs out.
An extension does not stop working when its license expires. It keeps serving filters, labels and payment methods, it does not show up in an error log, and the shop sells the day after exactly as it did the day before. Only one thing is gone: the entitlement to updates. That matters more than it sounds: in the WordPress ecosystem, where figures of this kind are analysed in public, 91% (Patchstack) of newly reported vulnerabilities do not sit in the core of the system but in the bought-in building blocks around it. No comparable analysis exists for the Shopware store; the construction of a lean core plus many bought-in extensions is the same, which is why the figure serves here as an analogy and not as a measurement of your own inventory. An expired license date raises no alert, causes no outage and produces no invoice - it quietly moves the shop into a state where the next flaw can no longer be closed.
Key takeaways
- In the WordPress ecosystem, 91% (Patchstack) of newly reported vulnerabilities affect extensions rather than the system core. No comparable analysis exists for the Shopware store; the finding is carried over here as an analogy from an equally modular system.
- In the same WordPress data set, the weighted median between disclosure and the first observed exploit is 5 hours (Patchstack); around half of all high impact flaws are attacked within 24 hours (Patchstack).
- Only 26% (Verizon) of vulnerabilities listed as critical were fully remediated, and full resolution takes a median of 43 days (Verizon).
- The Cyber Resilience Act requires a support period of at least five years (Official Journal of the EU) and the disclosure of its end date, stating at least the month and the year (Official Journal of the EU), at the time of purchase.
- A license register with expiry date, lead time and a named owner turns an invisible deadline into a scheduled task inside the maintenance contract.
Why a license deadline is not an accounting matter
Trading in extensions follows almost the same pattern everywhere: buying grants a permanent right of use, but the entitlement to updates only for a limited period, usually twelve months. When that period ends, the code stays on the server and keeps running unchanged. What ends is the channel. New versions appear at the vendor, but the shop is no longer offered them, and an update run simply reports that no newer version is available. From the inside the state looks exactly like „everything is current“ - and that confusion is the heart of the problem.
This silence sets a license deadline apart from almost every other deadline in operations. An expired certificate breaks the connection and is reported within minutes. An expired domain drops out of name resolution. An expired license, by contrast, produces no signal at all because technically it breaks nothing. That is also why ongoing monitoring does not catch it: monitoring measures availability, response times and error rates, and all three stay unremarkable while the update path has long since closed. To see the deadline you have to carry it as a date - in the inventory, not in an inbox.
What happens on the expiry date - and what does not
What the numbers say about the extension inventory
The order of magnitude explains why a register is worth the effort. One caveat belongs in front of it: every figure in this section comes from a vulnerability database for the WordPress ecosystem, because that ecosystem is analysed in public while the Shopware store is not. Carrying the figures over to a shop is therefore an assumption, resting on the same construction - a lean core, many bought-in extensions, each with its own deadline - and not on a measurement of your own inventory. In 2025 alone, 11,334 (Patchstack) new vulnerabilities were recorded there. Of those, 4,124 (36%) (Patchstack) were serious enough to require an immediate protective measure - not an update in the next maintenance round, but a rule that blocks the attack until the update arrives. The share attributable to extensions stands at 91% (Patchstack); the system core plays a minor supporting role in this statistic. Anyone who diligently updates the core while leaving the extensions alone is maintaining precisely the smaller part of the attack surface.
Two findings from the same WordPress data set run against the usual expectation. First, almost half of the reports were still open at the time of disclosure: 46% (Patchstack) of vulnerabilities had no timely fix from the developer. Second, the paid building blocks perform worse rather than better - when looking at attacks actually observed, they carried three times more (Patchstack) already exploited vulnerabilities than the free ones. The purchase price therefore does not replace the question of how long and how reliably the vendor maintains the extension. It merely moves that question to a place where it gets asked less often.
| Common assumption | What the data shows | Consequence for operations |
|---|---|---|
| The system core is the attack surface | 91% (Patchstack) of WordPress reports concern extensions | The review cycle starts with the extension inventory, not the core |
| Paid building blocks are better maintained | in the WordPress ecosystem, three times more (Patchstack) exploited flaws than free ones | Price does not replace a stated support period |
| A report arrives together with its fix | 46% (Patchstack) of WordPress reports were published without a timely fix | Plan for interim measures, not only for updates |
| Skipping an update leaves time | 5 hours (Patchstack) to the first observed exploit, WordPress data | Lead time instead of reaction, reserve maintenance windows up front |
| Discontinued extensions are obvious | 1,614 (Patchstack) extensions vanished from the WordPress repository within one year | Re-check the source regularly, not just the version number |
| The shop core sets a fixed cadence | Support transitions follow major releases, not fixed timelines (Shopware) | Tie planning to the release sequence, not to calendar years |
The last point hits operators particularly hard because it lies outside their reach. In the preceding reporting year, 1,614 (Patchstack) extensions and templates were pulled from the WordPress.org repository over unresolved security issues - an example from a different modular system that shows the mechanism, not a figure for the Shopware store. In the shop they carry on unchanged afterwards: the repository is where they disappear, not the installation. An extension inventory audit therefore checks not only runtime and effect, but also the plain question of whether the source still exists and who runs it today.
The window between disclosure and exploitation
The deadline that counts in an emergency is not the one on the license, but the one between the disclosure of a vulnerability and its exploitation. Weighted by observed exploitation intensity, the median in the WordPress data set is 5 hours (Patchstack). Around half of high impact vulnerabilities there are attacked within 24 hours (Patchstack). A maintenance window the week after next is therefore no longer a reaction but the documentation of lost time. And an extension without a valid license cannot even enter that race, because the fix is not offered to it - regardless of how fast the maintenance team otherwise works.
For vulnerabilities already listed as actively exploited, the distance to mass exploitation has barely moved across two reporting years: the median sits at five days (Verizon). In parallel, an average of 119 (BSI) new vulnerabilities per day became known during the reporting period. Taken together, the two figures describe a ratio that manual work can no longer resolve. The inflow is daily, the window is hourly, and the decision about each individual extension needs prepared rules rather than a case-by-case review that only starts once the report is already circulating.
The deadline is not the date, it is the lead time
That this lead time is missing in practice shows in the counter-check on remediation times. Full resolution of a vulnerability listed as critical takes a median of 43 days (Verizon) - almost two weeks longer than the year before. And only 26% (Verizon) of those vulnerabilities were fully closed at all, down from the previous year's figure. Exploitation of known vulnerabilities has meanwhile become the most common entry route into corporate networks at 31% (Verizon), pushing the abuse of stolen credentials off the top spot. Attackers therefore use exactly the route that an expired license holds open permanently.
The cadence of the shop system and the runtime
Extensions do not age on their own. They age against a cadence set by two other layers. The shop system publishes its minor versions Every first Monday of the month (Shopware) and its major steps once a year. More important than the rhythm is the coupling: the move into a lower support tier is tied to major releases, not fixed timelines (Shopware). Anyone who hangs their planning on calendar years is therefore planning past reality. The load-bearing axis is the release sequence, and the license deadlines of the extensions have to sit on that axis rather than on one of their own.
At the end of that sequence comes a tier that regularly surprises people in operations. A version outside regular support receives security fixes only (Shopware), and those fixes arrive through a dedicated security package instead of the familiar update route. For the extension inventory this means double work: the usual update command no longer applies, and every extension additionally has to be checked against the version for which fixes still exist at all. A durable update strategy therefore separates system upgrade, extension care and runtime from the outset - three deadlines, three owners, one calendar.
Extension inventory
Name, vendor, version, license end date, source and the question of whether that source still exists. Without those six entries, any deadline planning remains an estimate.
Expiry and lead time
Every license end date needs a second marker sixty or thirty days earlier. It marks the point of decision, not the point at which the renewal falls due.
System version
Which system version is the extension approved for? The next major step is decided at the weakest link in the chain, not at the core.
Runtime
The version of the scripting language carries its own deadline. It runs independently of any license and hits the entire inventory at the same moment.
Replacement and removal
For each extension a written answer to the question of what happens if the vendor stops: replace it, rebuild it in house, or switch it off and drop the feature.
Evidence
Date, decision and owner for every deadline. Without a record, nothing can later be shown to an insurer or in an audit.
The runtime beneath the shop deserves its own line in the register, because its deadline is the hardest of them all. Each release branch of the scripting language in use is fully supported for two years (The PHP Group) from its first stable release, followed by two additional years (The PHP Group) with security fixes only. Four years sounds generous. Measured against a marketplace that lists several thousand extensions (Shopware), each with its own license and approval deadline, it is a narrow window. How such a change succeeds without downtime is covered in the article on moving to a supported runtime.
What the Cyber Resilience Act demands in deadlines
European lawmakers have now put a binding name on the very deadline discussed here. Products with digital elements carry a support period of at least five years (Official Journal of the EU), unless the expected time in use is shorter. That period may no longer be an unknown at the point of sale: its end has to be stated, and the month and the year (Official Journal of the EU) are enough as a minimum. A figure that is simply missing from many offers today therefore moves into the product information - and, from an operator's point of view, into the checklist of every purchase.
remains available after it has been issued for a minimum of 10 years or for the remainder of the support period, whichever is longer
That passage requires every security update once issued to stay retrievable for at least ten years (Official Journal of the EU) or for the remainder of the support period. A download link that disappears together with the license does not satisfy it. The obligations phase in; the main body of the regulation applies from 11 December 2027 (Official Journal of the EU), with individual chapters earlier. Anyone buying an extension today without a stated support period carries that risk across the entire remaining life of the shop. Where a business also falls within the scope of the network security directive, a penalty range applies on top. A shop operator is caught by it, if at all, through the digital services of Annex II as an important entity; for that group Article 34(5) names EUR 7 000 000 (Official Journal of the EU) or 1.4% (Official Journal of the EU) of total worldwide annual turnover. Which of the two figures governs is not decided by how the entity is classified but by the wording itself: whichever amount is higher. The larger range of EUR 10 000 000 (Official Journal of the EU) or two percent sits in Article 34(4) and covers essential entities only. The resulting duties are broken down in the article on obligations under the network security directive.
#!/usr/bin/env bash
# Read the license register: report expired deadlines and everything inside the lead window
set -euo pipefail
REGISTER="/srv/shop/maintenance/licenses.csv"
# Columns: name;vendor;version;license_until;lead_days;owner
TODAY=$(date +%s)
tail -n +2 "$REGISTER" | while IFS=';' read -r name vendor version until_ lead owner; do
end=$(date -d "$until_" +%s)
left=$(( (end - TODAY) / 86400 ))
if [ "$left" -lt 0 ]; then level="EXPIRED"
elif [ "$left" -le "$lead" ]; then level="LEAD"
else level="ok"
fi
[ "$level" = "ok" ] && continue
printf '%-8s %-26s %-9s %5d days until %s %s\n' \
"$level" "$name" "$version" "$left" "$until_" "$owner"
done
A license register that makes expiry visible
A license register is not a database, it is a habit. A table with six columns is enough, provided it is touched on every purchase, every renewal and every decommissioning. What matters is less the tool than the question of who touches it and when. In Shopware maintenance the register hangs off the monthly maintenance run: the inventory is reconciled against the installation, every deviation is noted, and every deadline inside the lead window becomes a decision with a name and a date attached. Whatever can be automated should be automated - the rest stays a job for people, because the answer „replace or switch off“ is rarely a technical one.
- Full inventory read out of the installation, not reconstructed from memory or from old invoices.
- Per extension: vendor, purchased version, installed version, license end date, lead time and the responsible person.
- Source checked - does the vendor still exist, is the extension still listed in the repository, is there a successor version?
- Approved system versions noted per extension, so the next major step does not fail at the weakest link.
- Dependencies of the extension recorded; how quickly a third-party library becomes your own problem is shown in the article on attacks through the supply chain.
- Lead-time notice sent to an address that is actually read - not to a shared mailbox without an owner.
- Every renewal installed on a copy first; how such a test environment is set up cleanly belongs to the register as well.
- Decision, date and reasoning recorded, so the evidence exists later without reconstruction.
The most common mistake when building the first register is taking completeness from the invoices instead of from the system. Invoices show what was bought; the installation shows what is running. In between there are usually deactivated building blocks that still ship code, test installations that quietly went live, and extensions from projects nobody remembers. Only reconciling both sides produces a register that holds. How ongoing security updates attach to it is decided at the same point: without a dependable inventory, every prioritisation is guesswork.
Four routes when a deadline runs out
Renew
The standard case when the extension is needed and the vendor is active. Timing is what matters: the renewal belongs in the lead window, not on the expiry date. After that comes installation on a copy, a short run through the affected paths, and only then the maintenance window.
Replace
When the vendor stops responding, the extension has vanished from the repository, or approval for the next system version is missing. A switch needs more lead time than a renewal, because data, settings and interfaces have to move along with it.
Switch off
The underrated option. Many extensions are leftovers of old requirements. Dropping the feature lowers the maintenance load permanently and removes an attack point entirely - provided the code is uninstalled and not merely deactivated.
Shield
The intermediate step when none of the above is possible right away. A blocking rule in front of the vulnerable spot holds the attack off until the decision is made. How such an assessment runs cleanly is described in the article on handling vulnerability reports.
The standard case when the extension is needed and the vendor is active. Timing is what matters: the renewal belongs in the lead window, not on the expiry date. After that comes installation on a copy, a short run through the affected paths, and only then the maintenance window.
When the vendor stops responding, the extension has vanished from the repository, or approval for the next system version is missing. A switch needs more lead time than a renewal, because data, settings and interfaces have to move along with it.
The underrated option. Many extensions are leftovers of old requirements. Dropping the feature lowers the maintenance load permanently and removes an attack point entirely - provided the code is uninstalled and not merely deactivated.
The intermediate step when none of the above is possible right away. A blocking rule in front of the vulnerable spot holds the attack off until the decision is made. How such an assessment runs cleanly is described in the article on handling vulnerability reports.
One limitation of the fourth route deserves to be said out loud: a blocking rule is an interim measure with its own expiry date, not a substitute for the fix. It buys time on the order of days to weeks, and it has to be documented, otherwise it stays in place after remediation and becomes a source of faults at the next rebuild. If an interim state gets out of hand, emergency support takes over - although every hour invested in lead time beforehand reduces the need for it.
What a closed update path costs in operations
In retail, exploitation of vulnerabilities is by a wide margin the most common entry route in confirmed breaches at 42% (Verizon). In 68% (Verizon) of cases a third party is involved as well: a service provider, a host, or precisely this kind of bought-in software. Across all sectors, the share of incidents involving a third party stands at 48% (Verizon). An extension without an update entitlement is exactly such a third party - only one that nobody looks after any more. How quickly such a state reaches visibility is shown in the article on the new mandatory notice on product pages, which can disappear just as quietly after a system upgrade.
German survey data supports the picture from the operator's side. Among affected companies, technical vulnerabilities were a reason for the damage in 50 percent (Bitkom) of cases, and outdated hardware or software in 43 percent (Bitkom). Cyber attacks now account for 76 percent (Bitkom) of total damage, whose annual scale is given as EUR 211 billion to EUR 270.8 billion (Bitkom). Those are figures for the whole economy rather than for a single shop; their meaning for operations lies in the ratio: the share traced back to outdated software is not a marginal item.
Silent failure
The shop keeps running, the fix does not arrive. The state is invisible from outside and from inside until somebody exploits it.
Visibility
After a forced system upgrade, settings change along silently; how to monitor indexability therefore belongs in the same cycle.
Time pressure
Without an update entitlement only a rebuild under time pressure remains - the most expensive moment for a decision that could have been taken calmly twelve months earlier.
Chain effect
An unmaintained extension blocks the next system upgrade and with it the update of every other building block at the same time.
More than one system
Anyone running further sites alongside the shop keeps two deadline lists; in WordPress maintenance the same logic applies with different cycles.
Burden of proof
Insurers and audits ask about the state at the time of the incident. Without records from monitoring and from the register, only memory remains.
That this burden falls mainly on small and medium-sized businesses is not a guess: around 80 percent (BSI) of reported attacks were directed at small and medium-sized enterprises. At the same time the market these businesses work in keeps growing - German online retail most recently reached EUR 92.3 billion in turnover (HDE), and around 19.9% (Web Almanac) of the websites analysed are shops. The shop system market itself is a long tail of small systems: 362 (Web Almanac) detected systems stood against a mere handful with a meaningful share. For the individual operator that means the update path of their extensions hangs on a small number of vendors - and every license deadline makes a dependency visible that would otherwise go unnoticed.
How expiry enters the maintenance cycle
All of this adds up to a plain operating routine. Once a month the inventory is reconciled against the installation, every deadline inside the lead window produces a named decision, and every decision is recorded with a date. Twice a year the question of the system version joins in: which extension blocks the next upgrade, and what is the plan for it? This routine needs no new software, but a fixed place in the maintenance contract and a person who owns it. The gain is unspectacular and valuable for exactly that reason: there is no longer a day on which an extension silently drops out of maintenance.
Sources and studies
Related Articles
Moving Shop Servers Without Losing Orders: A Runbook
Resolvers may keep serving stale DNS answers for 1 to 3 days. How a shop moves servers without losing orders, cron jobs or payment notifications.
Hosting provider or maintenance: who patches what
Where the hosting provider’s responsibility ends and maintenance begins: a matrix across every layer of the shop, questions to ask and clear handover points.
End of support under the shop: OS and database
Debian 11, MariaDB 10.6 and MySQL 8.0 dropped out of maintenance in 2026. How to inventory distribution, database and PHP and plan the upgrades with lead time.