Mainstream Support Ends 13 October: What Unsupported Server Software Does to an Indian Cyber Policy

CERT-In advisory CIAD-2026-0042, issued in August 2026, records that mainstream support for Windows Server 2022 ends on 13 October 2026. Nothing about that is a surprise. It is a vendor-published lifecycle milestone, fixed years in advance, sitting in the public record with a date and an attributable source.

That is precisely why it matters to anyone buying or renewing cyber cover in India. Most coverage disputes turn on facts that are expensive to establish. Was multi-factor authentication actually enforced on the VPN, or only configured? Was the backup immutable, or merely offsite? Those questions need forensics, log preservation and often a fight between two experts. An end-of-support date needs none of that. A claims manager can establish it from a vendor lifecycle page and an asset list, and the asset list usually comes from the insured's own incident report.

Any cyber policy incepting or renewing before 13 October 2026 on a twelve-month term will still be on risk when the date passes. If the insured estate still carries Windows Server 2022 hosts on that date, and the wording contains a minimum-security condition, an unsupported-software exclusion or a patching warranty, the insurer has acquired a documentary argument that costs it almost nothing to run. The question for brokers and risk managers is not whether the date will be noticed. It is whether the policy wording has been drafted so that noticing it decides the claim.

Indian cyber wordings, many of which follow London market forms and are filed through IRDAI's use-and-file route, handle unsupported software in one of three ways. They look similar on a first read and behave very differently at claim.

1. An exclusion. The policy excludes loss arising out of, caused by or contributed to by software, firmware or hardware that the manufacturer no longer supports. This sits in the exclusions schedule alongside war, bodily injury and prior known circumstances.
2. A condition precedent to liability. The insured undertakes to maintain supported and patched systems, and compliance is expressed as a precondition to the insurer's obligation to pay. Failure does not need to have caused the loss for the insurer to argue the obligation never attached.
3. A warranty or minimum-standards endorsement. The schedule carries a specific promise, usually that critical and high-severity patches are applied within a stated window (14, 30 and 45 days are the windows most often quoted) and that no internet-facing system runs software beyond vendor support.

A fourth treatment is becoming more common and is worth asking for. Instead of removing cover entirely, the wording applies a raised retention or a coinsurance percentage (often in the region of 10 to 25 percent of the loss) where an unsupported asset is in the causal chain. The insured keeps cover, the insurer keeps a price signal, and neither side is arguing about whether the entire tower falls away because one print server was missed.

The drafting label decides the shape of the argument, so it is the first thing to check on any wording that mentions supported software.

Where the obligation is drafted as an exclusion, the burden usually sits with the insurer to show that the loss arose from the excluded circumstance. That is a causation question, and causation questions are winnable. If the intrusion came through a phished credential and lateral movement across fully patched Linux hosts, the presence of an out-of-support Windows box in a lab VLAN is not obviously the proximate cause of anything.

Where the obligation is drafted as a condition precedent or a warranty, the argument moves upstream. The insurer says the contractual precondition was not satisfied, so the question of what caused the loss never arises. Insureds sometimes assume Indian courts will read a causal requirement into such clauses. That is a hope, not a drafting strategy, and it is a hope that gets tested after the loss rather than before it.

The three amendments worth asking for

• Insert a causal link. Amend the clause to bite only where the unsupported software "caused or materially contributed to" the loss. This single edit converts the harshest form into something close to the exclusion form.
• Insert a materiality or scope carve-out. Limit the clause to internet-facing systems, or to systems processing personal or payment data, so that an isolated laboratory or test asset cannot void a production claim.
• Insert a remediation window. Where a product moves out of support during the policy period, the insured gets a defined period (60 or 90 days is a reasonable ask) to remediate, isolate or compensate before the clause applies. Support end dates are known in advance, so this is not an unreasonable request to put to an underwriter.

Record any of these as a written endorsement on the schedule. A broker's email confirming an underwriter's relaxed reading of a clause is not a policy term and will not survive a change of claims handler.

This is the trap in the 13 October date, and it cuts both ways.

Vendor lifecycle policies distinguish between phases. The end of mainstream support is a defined milestone in Microsoft's product lifecycle and it is not, by itself, the point at which a product stops receiving security updates. Many cyber wordings, however, do not borrow the vendor's vocabulary. They say "no longer supported by the manufacturer", "unsupported operating system", or "beyond end of life", and they leave the term undefined.

An undefined support test lets an insurer point at a vendor page that says mainstream support ended on 13 October 2026 and argue the condition is met, even where security updates were still flowing to the asset on the date of loss. The insured is then arguing about the meaning of a word rather than about its own security posture, which is an expensive place to be.

The fix is definitional, not technical. Ask for the clause to key off the availability of security updates rather than "support" in the abstract:

Unsupported Software means software for which the manufacturer no longer makes security updates available to the Insured, whether under standard lifecycle terms or under a paid extended support programme purchased by the Insured.

That wording does three things. It ties the test to the risk the underwriter actually cares about, which is whether known vulnerabilities can be patched. It preserves cover through the mainstream-to-extended transition. And it gives credit to an insured that has paid for extended support, which the undefined version does not.

If the estate will carry paid extended support past a lifecycle milestone, disclose it at proposal stage and get it reflected in the definition. Extended support purchased quietly and never disclosed is a control the underwriter cannot price and the claims team will not credit.

The Windows Server 2022 milestone did not arrive alone. In the same August 2026 window, CERT-In issued CIAD-2026-0040 covering vulnerabilities across SAP products that enable privilege escalation, authorisation bypass, spoofing and unauthorised access, and CIVN-2026-0416 covering a critical server-side request forgery flaw in MLflow.

Read as an underwriting signal, those three advisories describe three different failure modes in the same estate:

• The operating system layer, where lifecycle dates are published years ahead and non-compliance is a planning failure rather than a detection failure.
• The ERP layer, where SAP patching is slow because change windows are contested, testing is heavy and the business owns the downtime decision rather than IT.
• The data science layer, where tools such as MLflow are frequently installed by teams outside the IT change process and are often absent from the configuration management database entirely.

That third category is the one that breaks patching warranties. A warranty to patch critical vulnerabilities within 30 days is a promise about assets the organisation knows it has. An experiment-tracking server stood up on a cloud instance by a model team, never entered in the asset register and never scanned, is outside the process the warranty describes and inside the definition the warranty uses.

This is why underwriters have shifted their questions. The proposal form asks less about whether a patching policy exists and more about how the asset inventory is built, how often it is reconciled against network discovery, and who signs off on shadow infrastructure. An insured that can produce a reconciled inventory is making a materially different disclosure from one that can produce a policy document.

The other side of this file moved in 2026. IRDAI's Insurance Fraud Monitoring Framework Guidelines, issued on 9 October 2025, came into force on 1 April 2026. They expressly recognise cyber fraud as a distinct threat category, require insurers to maintain board-approved fraud risk policies, and require reporting of frauds above Rs 1 crore within 30 days.

For a commercial buyer, the practical consequence is procedural rather than doctrinal. Every Indian insurer now runs a documented fraud function with board-level oversight, defined escalation paths and reporting deadlines it has to meet. Claims that carry indicators of misstatement get routed into that function rather than being settled through negotiation between a broker and a claims manager.

Set that against a proposal form. A cyber proposal typically asks whether all systems are within vendor support and whether critical patches are applied within a stated window. If the answer given in September 2026 is yes, and the forensic report in December 2026 lists Windows Server 2022 hosts that went out of mainstream support on 13 October with no compensating controls recorded, the file now has two problems rather than one. The coverage problem is the warranty. The second problem is that an inaccurate material answer, on a contract governed by utmost good faith, is exactly the pattern a fraud framework is designed to flag.

The defensive move is unglamorous. Answer proposal questions with qualifications where qualifications are true. "All internet-facing systems are within vendor support; 14 internal hosts run Windows Server 2022 and are scheduled for migration by 31 December 2026, with network segmentation and EDR applied in the interim" is a better answer than "yes", and it is a far better answer than "yes" plus a forensic report that contradicts it. Underwriters price disclosed exposure. They decline undisclosed exposure.

Work through this before the next cyber renewal, and keep the evidence in a file the claims team could be shown without editing.

1. Pull the lifecycle inventory. List every operating system, database, hypervisor and appliance in the estate against its vendor support end date. Flag everything with a milestone inside the next 18 months, not just the ones already past.
2. Map the estate against the policy language. For each flagged asset, decide whether it is internet-facing, whether it processes personal or payment data, and whether it would fall inside the wording's definition of unsupported software as currently drafted.
3. Get the clause classified. Have someone state in writing whether the obligation is an exclusion, a condition precedent or a warranty. Brokers should provide this as a matter of course on any cyber placement.
4. Negotiate the three amendments. Causal link, scope carve-out for non-internet-facing and non-production assets, and a remediation window for products that exit support mid-term.
5. Define unsupported software by reference to security updates, and capture paid extended support inside the definition.
6. Reconcile the asset register against network discovery before completing the proposal form, specifically looking for data science, analytics and developer tooling that was never registered.
7. Document compensating controls for anything that will still be out of support at inception: segmentation, EDR coverage, virtual patching, restricted egress, removal of internet exposure. Attach the document to the proposal rather than describing it in a call.
8. Qualify every proposal answer that cannot be answered with an unqualified yes, and keep the working papers that support each answer.
9. Diarise 13 October 2026 and the equivalent date for every other flagged product, and confirm in writing what changed on that date in the estate.

The broader point is that cyber insurance has moved from a product priced on revenue and sector to one priced on the specific controls an insured can evidence. Our note on cyber insurance underwriting challenges in India sets out how that assessment is built, and the capacity and pricing outlook for 2026 covers what that has done to terms. A published support end date is the easiest control failure in the entire set to prove, which is exactly why it deserves attention before it arrives rather than after.