Microsoft Product Terms Update: August 2026

Microsoft published changes across eight areas of the Product Terms on 1 August 2026. Several are labelled as clarifications or product-name updates.

The most extensive revision is in the Professional Services terms that govern engagements delivered without a separate services agreement. Microsoft has extended the warranty disclaimer from free deliverables to all Services Deliverables, placed broader responsibility for decisions, deployment, and recovery on the customer, and added an intellectual property structure for improvements, developments, and knowledge retained in unaided memory.

Two other changes require more context than their compact Product Terms entries provide. Web IQ, Microsoft's new set of web-grounding APIs for AI applications, is expressly outside the Microsoft Products and Services Data Protection Addendum (DPA), and Customer Data used with it will leave the customer's compliance and geographic boundary. Microsoft has also expanded the Enterprise Agreement (EA) and Enterprise Agreement Subscription (EAS) terms for Windows Server Extended Security Updates (ESUs). The new wording covers eligible workloads running on Azure virtual machines or connected through Azure Arc. Under those terms, the underlying Windows Server licences for Arc-connected workloads must remain covered by Software Assurance or an equivalent subscription for the full ESU period.

The remaining changes are narrower. Government plans now qualify as base licences for Microsoft 365 Copilot, and several Defender Experts products have new names. Microsoft has also revised the wording on copyright protection for AI output and on the notice it gives before retiring an Azure service or feature. It describes both revisions as clarifications.

Key takeaways:

• Professional Services: Microsoft still promises that its consultants will work professionally, but no longer warrants the code, designs or recommendations they leave behind, even when paid for. Customers are responsible for deciding whether to use that work and for putting it into operation. New terms also determine who owns it

• Web IQ: Microsoft must approve each application before it can use Web IQ. Data sent to the service falls outside the Microsoft DPA and leaves the customer's compliance and geographic boundary. Separate terms govern how results may be used, shown and stored, and what activity must be reported to Microsoft

• Software Assurance Benefits: the EA/EAS ESU terms now cover Windows Server workloads on Azure virtual machines and servers connected through Azure Arc. Under those terms, Arc-connected servers must keep Software Assurance or an equivalent subscription for the full ESU period

• Microsoft 365 Copilot: Microsoft 365 and Office 365 G3/G5 plans now qualify as the base licence required for Microsoft 365 Copilot

• Customer Copyright Commitment: customers using a covered AI product with configurable instructions or safety systems must follow Microsoft's published safeguards to keep the copyright protection Microsoft offers, even if they leave the default settings unchanged. A related wording change now refers to "any Copilot", but does not name a newly covered product

Professional Services warranties, responsibilities and ownership

TL;DR: Microsoft still promises that its consultants will do a professional job. But it makes no promises about the code, designs, recommendations or other material they leave behind, even if you paid for it. If you use that material, you are responsible for testing it, deploying it, keeping it running and recovering if something goes wrong. If Microsoft modifies something you brought into the project, you own the modification. If it creates a new agent, proof of concept or other work from scratch, Microsoft owns it, although you can use and change it inside your organisation. The warranty, responsibility and ownership rules described here are the defaults; a separate services agreement may set different ones.

The Professional Services terms are easy to overlook because they do not describe a licence or a cloud service. They govern a different part of the Microsoft relationship: the advice, engineering, workshops, proofs of concept and other work Microsoft performs for a customer. They apply when the services are purchased under the customer's volume licensing arrangement, and no separate Professional Services agreement takes precedence. Where there is a separate agreement, the Product Terms say that agreement governs, and the most current applicable terms control if there is a conflict.

Agents, prompts and proofs of concept left behind by an AI engagement are typical Services Deliverables: under the August terms they ship as-is, whether or not you paid for them.

Not every Microsoft consulting project uses these standard terms. A separate services agreement may say something different. The changes below apply when there is no separate agreement.

What Microsoft promises about its consulting work

The first change is only a few deleted words. Microsoft has long warranted that it will perform Professional Services with professional care and skill. If it fails to do so and the customer gives notice within 90 days of performance, Microsoft's stated remedy is to perform the services again or refund the price paid. That limited service-performance warranty remains.

The separate disclaimer for the output of the engagement used to say that Services Deliverables provided without charge were supplied as is and without warranty. August removes the qualification. Under the current wording, all Services Deliverables are provided "AS-IS, WITHOUT ANY WARRANTY". Payment no longer moves a deliverable outside that disclaimer.

Microsoft draws a line between the consulting work and what its consultants leave behind. The service is the work itself. The deliverable is the result: a proof of concept, document, design, sample code, software library, algorithm or machine-learning model.

Microsoft may do the consulting work professionally and still make no promise that the deliverable is ready for production, suitable for the customer's needs or free from claims that it infringes someone else's rights. Microsoft's promise covers how its consultants work, not whether the result will work for the customer.

Who is responsible when the result is put into use

Consider a common AI engagement. Microsoft helps a customer construct an agent, connects it to selected internal sources and leaves behind code, prompts, an architecture and a proof of concept. The engagement may meet its statement of services and the consultants may exercise professional care. The August terms nevertheless place responsibility on the customer for testing, deploying, maintaining and supporting what was supplied or recommended. If an untested connector, a tenant configuration change or an inadequate recovery design later causes a production failure, the standard terms point to the customer's implementation duties and the as-is disclaimer. Whether another remedy remains available depends on the complete contractual position and the nature of the failure.

Microsoft now says the customer is responsible for what it does with the advice and materials it receives. That includes deciding whether to follow a recommendation, changing the tenant or IT environment, testing the result, backing up systems and recovering if something goes wrong. The responsibility begins with the decision to proceed and continues through implementation and operation.

The warranty has not disappeared, but it is narrow. Microsoft still promises to perform the consulting work professionally. If it fails to do that, the customer has 90 days to raise the issue. Microsoft's stated remedy is to do the work again or refund the price.

A failure in the code, design or model raises a separate issue. Microsoft can point to the as-is disclaimer and to the customer's responsibility for testing and deployment. If the dispute reaches court, one key question would be whether Microsoft performed the consulting work badly or whether the problem arose from the deliverable after the customer put it into use.

Who owns the work created during the project

The next question is who owns the result. The answer depends on where the work started. The terms distinguish between material that existed before the project, changes made to that material and entirely new work created during the engagement.

Source: Microsoft Product Terms, Professional Services.

Anything that existed before the project remains with its original owner. Suppose the customer brings its own code, document or design into the engagement and Microsoft changes it. Microsoft calls the changed version an Improvement. The customer owns that improvement, even though Microsoft did the work, and Microsoft must transfer any rights needed to give effect to that ownership. The same rule applies in reverse. If the project improves something Microsoft already owned, Microsoft owns the improvement.

The customer owns an improvement to its material, but Microsoft may still reuse the generic part of an improvement it created. It may use, copy, change and distribute that generic element worldwide without paying a further fee. It may not transfer that right to another party, and the material it reuses must not disclose Customer Data or the customer's confidential information. In practical terms, Microsoft can reuse a general method or component that could serve other customers. The clause does not allow it to publish the customer's source code, architecture or confidential implementation.

The position reverses when Microsoft creates something new that is not based on the customer's existing work. A new technology, document, proof of concept or agent can be a Development under the terms. Microsoft owns it. The customer may use, copy and change it worldwide for its own internal business, without paying a further licence fee. That right is not exclusive and cannot be transferred to another party. It is also subject to the Product Terms and the statement of services for the engagement.

What if the same project produces both kinds of work? Microsoft might adapt a customer-owned orchestration framework and also create a separate agent. The adaptation may be an improvement owned by the customer. The separate agent may be a development owned by Microsoft if it does not contain the customer's existing work. Paying for the project does not settle the question. Nor does the fact that the work was created for one customer's needs. Ownership follows where each part of the work began.

This distinction becomes important when the result is meant to travel beyond the team that commissioned it. The Product Terms separately allow a customer to let its affiliates use Services Deliverables, although those affiliates cannot pass the rights on again. At the same time, the customer's right to use a Microsoft-owned development is limited to its internal business and cannot be transferred. How those provisions apply may depend on the type of work produced and on the statement of services. The question can arise when a group wants to deploy a proof of concept across subsidiaries, give it to an outsourcer, include it in something supplied to customers or keep using it after a divestment. Commissioning and paying for the work do not by themselves grant all of those rights.

What you may retain after the project ends

The final addition deals with what people remember after the project ends. Microsoft calls the retained knowledge Residuals. A consultant or customer employee may retain general ideas, methods and experience without keeping a copy of the other side's material. The new clause allows either party to use that general knowledge later without creating liability under the Product Terms or trade-secret law.

The protection is deliberately limited. It applies only to knowledge that remains in a person's unaided memory. It does not cover deliberate memorisation of confidential information, disclosure of Customer Data or disclosure of the other party's confidential information. It does not give Microsoft permission to copy or disclose the customer's documents, code, data or confidential designs. It recognises the more ordinary point that people cannot erase their general professional experience when an engagement ends.

Taken together, the August changes set the default for consulting projects governed by the Product Terms. Microsoft promises to carry out the consulting work professionally, but the material it leaves behind comes without a warranty, and the customer is responsible for putting it into operation. Ownership then follows where the work began. Changes to the customer's existing material belong to the customer. Separate new work created by Microsoft belongs to Microsoft, although the customer may use and change it inside its own organisation. Microsoft may also reuse the generic elements of improvements it creates, but it cannot use that right to disclose Customer Data or the customer's confidential information.

For a workshop that produces little more than a presentation, some of these distinctions may never become visible. When an engagement produces code, an agent, a migration design or an operating model intended for use across a wider business, however, the rules can determine who may use, change or share the result. A statement of services may describe the work, timetable and price in detail while leaving these default rules unchanged.

Web IQ data protection and use terms

Web IQ is Microsoft's new family of APIs for supplying web, news, image and video context to AI agents and assistants. Microsoft describes the output as structured and ready for citation, using Bing search infrastructure to help a model answer with current information rather than relying only on what was present in its training data. The August Product Terms add Web IQ in two places. The Azure terms make access subject to Microsoft's review and approval, while the Privacy & Security Terms add it to the table of services to which the DPA does not apply.

The DPA does not apply, and data leaves the customer's boundary

That privacy position deserves to be read before the feature description. The Product Terms state that use of Web IQ is governed by the Microsoft Privacy Statement and that Customer Data will flow outside the customer's compliance and Geo boundary. The separate Web IQ Terms of Use go further. They say that Microsoft may collect an end user's IP address, the requests sent to Web IQ, submission times and the results returned. Queries and responses may contain personal data. Microsoft and the customer act as independent controllers for personal data transferred under those terms, not as joint controllers. Each party is responsible for its own privacy notices and handling of data-subject requests.

Using Web IQ through Azure does not bring the data protections that normally apply to Azure Online Services. The Product Terms expressly exclude Web IQ from the DPA and say that Customer Data moves outside the customer's compliance and geographic boundary. Microsoft's public terms do not say where that data goes. An organisation therefore cannot infer the processing location from the location of the surrounding Azure workload. Nor can it assume that the EU Data Boundary, a selected Azure region or its ordinary DPA commitments contain the Web IQ request and response.

Imagine an agent used by a legal, support or procurement team. The agent sends a web-grounding query that includes a customer's name, an incident description, a disputed contract term or a fragment of internal context to make the search more precise. The application itself may run in the organisation's chosen Azure region. Even so, the Product Terms say that Customer Data in the Web IQ exchange leaves the compliance and Geo boundary. Under the dedicated terms, Microsoft and the customer each handle the relevant personal data as an independent controller. A technical diagram may show one agent and one Azure subscription, but the contractual data path has another branch.

Microsoft approves each application separately

Approval is only the first gate: the display, storage and reporting rules sit in separate Web IQ terms outside the Product Terms and the DPA, and Microsoft says those requirements may be updated.

Access is controlled separately from ordinary Azure consumption. A customer must accurately register its proposed use, and Microsoft may approve or deny access at its discretion. Approval applies only to the application described. Another application requires another registration. The customer also needs an active Azure account and must use the subscription key supplied by Microsoft as the only access method. Microsoft's marketing page describes current access as limited. It says selected enterprise customers working with Microsoft account teams on production AI workloads are prioritised. That description does not promise that any particular customer or use case will be approved.

Microsoft's Product Terms change description calls Web IQ a "Limited Access Service". The live terms are less tidy. Web IQ does not currently appear by name in the general list of Limited Access Services. Instead, it has its own review-and-approval paragraph, while Microsoft's Web IQ page uses "limited access" as a description. The approval requirement is clear. The available documents do not establish that every general rule for the defined category of Limited Access Services also applies to Web IQ. The capitalisation in the change description is not enough to settle that point.

How Web IQ content may be used and displayed

Approval does not end the restrictions, and Microsoft's terms draw several distinctions that are easy to miss. Content is the broad label for what Web IQ returns, including Grounding Content, search results, images and videos. Grounding Content is the subset that an application may use to ground a language model for a particular query, including titles, URLs, snippets, news results, metadata, alternative text and passages. The LLM Summary is the new output the model creates from that material. For an application using Web IQ to ground a model, the dedicated terms allow the customer to display Content alongside the model's answer and to use Grounding Content for that specific query and end user, with the required source attribution, to create the LLM Summary. Other implementations fall under separate Search Use rules.

Neither route permits Content to be used to train, evaluate or improve a language model. Content may be used only in the approved application and cannot be redistributed, resold or used to create a substitute or competing service. Returned images and videos receive tighter treatment than text. The media themselves cannot be used for model grounding, placed in model output or turned into derivative media, although associated metadata and alternative text may qualify as Grounding Content.

The display rules make Web IQ different from a generic search feed whose results an application can incorporate without visible attribution. Sources used for grounding require nearby attribution and links. An excerpt from one source cannot exceed 200 characters and may need to be shorter if the source owner sets a lower maximum. Restrictions imposed by the source site, including relevant crawler controls, still apply. Search results generally have to preserve attribution, URLs and ranking. The application must also make clear that the material came from the internet. The customer bears any publisher licence fees arising from its display or use of responses. The Web IQ terms also make the customer responsible for certain third-party claims connected with that display or use.

Storage and reporting follow separate rules

Storage follows the same distinctions. For LLM Use, the Web IQ terms allow an LLM Summary to remain in an individual end user's chat history for up to 30 days, or longer if the customer refreshes it within that period. They also allow the summary and its attribution links to be stored as an integrated part of the customer's internal work product where copyright law permits. Neither permission extends to the underlying Content. Content kept solely to complete a single logical request or workflow, which Microsoft calls an Atomic Action, may remain only in a transient processing state and must be deleted immediately when that action finishes. Under the separate Search Use rules, the 30-day chat-history exception covers only image and video URLs.

The terms also require the customer to implement Microsoft's callback API within 60 days of the stated Effective Date. For each response, the callback must send the result URLs or citations, the session identifier and the citations on which the end user acted. It must send that information in real time and no later than 15 minutes. The terms describe failure to meet the callback requirement as a material breach.

The Web IQ terms do not visibly include a date and do not define the "Effective Date" used for that 60-day deadline. The starting point for the deadline is therefore unclear. The rules are also easy to miss because they do not all sit in the Product Terms. The short Azure entry links to a much longer web page containing the use, display, storage, publisher and reporting rules, and that page says its requirements may be updated. A customer may complete the Azure purchase and access steps yet still miss obligations that sit outside the familiar Product Terms and DPA structure.

Web IQ may be useful precisely because it lets an agent reach beyond a fixed enterprise corpus. That same movement beyond the corpus raises separate questions about where the data goes, how source material may be used and what the application must report. Web IQ is more than a search setting on an Azure model. Microsoft must approve the application, the data sent to Web IQ sits outside the DPA, and the service has its own rules for using content and reporting activity.

Windows Server ESU on Azure and Azure Arc

Extended Security Updates keep critical and important security fixes available after a product leaves extended support. They are a bridge for workloads that cannot be upgraded or retired by the support deadline, usually for up to three additional years. Coverage is limited and, for most routes, separately priced. It does not return a server to mainstream support or restore ordinary product fixes; the migration or retirement work remains.

The August Software Assurance Benefits update adds a section for Azure and Azure Arc-connected workloads. It says a customer may acquire ESU coverage for eligible Windows Server workloads running on Azure virtual machines or connected through Azure Arc. For an Arc-connected workload, the customer must maintain active Software Assurance or equivalent subscription licences corresponding to the underlying Windows Server licences throughout the applicable ESU coverage period.

The EA/EAS terms require active coverage throughout an Azure Arc ESU period

The new EA/EAS duration rule is specific to Azure Arc. The Product Terms attach it to the way the workload receives ESUs, not to a particular Windows Server release. Under the general EA/EAS rule, a customer needs at least one month of qualifying Software Assurance or subscription coverage remaining at the beginning of each ESU coverage year. For a workload connected through Azure Arc under those terms, however, that coverage must remain active for as long as the Arc-enabled ESU coverage remains active. A customer therefore cannot keep Arc-enabled ESU running after the underlying Software Assurance or subscription coverage expires.

Price and eligibility vary by Windows Server release and delivery route

For the remaining Windows Server 2012 and 2012 R2 coverage period, eligible Azure virtual machines receive ESUs at no additional charge and do not require Software Assurance for the ESU benefit itself. That legacy programme ends on 13 October 2026. The same releases follow different commercial rules when they are connected through Azure Arc, where ESU coverage is purchased through Azure and billed monthly. The traditional route instead uses annual ESU licences and activation keys.

Windows Server 2016 does not receive the same free-Azure treatment. Extended support ends on 12 January 2027, and Microsoft's services pricing consistency policy says that new Windows ESU offerings released on or after 1 April 2026 will carry the same list price whether a workload runs in Azure, on-premises or in another public cloud. An official Azure Arc post confirms that the affected new offerings include Windows Server 2016. Moving a Windows Server 2016 workload to an Azure virtual machine therefore does not reproduce the free Azure ESU exception attached to Windows Server 2012 and 2012 R2.

The Product Terms establish the general eligibility framework without naming Windows Server releases, editions or prices. Microsoft's current Azure Arc licensing guidance supplies the release-specific detail. For Windows Server 2016, it describes Azure Arc ESU as a paid service billed monthly, requires active Software Assurance or an equivalent Server Subscription and excludes SPLA as an eligible underlying licence. Microsoft's public Azure Arc pricing page has not yet supplied the Windows Server 2016 dollar rates, so the eligibility rules and Microsoft's pricing principle are clearer than the eventual invoice amount.

At a high level, the three delivery routes compare as follows:

Sources: Azure virtual machine and traditional annual routes: Microsoft Extended Security Updates lifecycle FAQ; Azure Arc: Microsoft Product Terms, Software Assurance Benefits (EA/EAS) and Azure Arc-enabled ESU licensing guidance; Windows Server 2016 pricing treatment: Microsoft services pricing consistency policy and Microsoft Azure Arc announcement.

MCA subscriptions can qualify without Software Assurance

MCA does not provide Software Assurance. The MCA view of Software Assurance Benefits says that these benefits are unavailable under both the Microsoft Customer Agreement and the Microsoft Cloud Agreement. Windows Server subscriptions use a different route. The MCA Windows Server terms list Windows Server ESU and say that an active subscription carries rights equivalent to those given to Software Assurance customers. The August ESU wording recognises the same two forms of underlying coverage: active Software Assurance or an equivalent subscription licence.

The two pages answer different questions. The Software Assurance page confirms that MCA customers do not receive Software Assurance, while the Windows Server page explains the rights that come with an active subscription. In this context, "equivalent" means that the subscription can meet the underlying ESU eligibility requirement without becoming Software Assurance. For paid ESU routes, the customer must still obtain the annual coverage or pay the Azure Arc charge; the active subscription establishes eligibility for that coverage.

The remaining uncertainty concerns the new August rule that requires Azure Arc customers to keep the underlying coverage active throughout the ESU period. That paragraph appears in the EA/EAS view of Software Assurance Benefits, while the MCA view continues to say that Software Assurance Benefits are unavailable. The MCA Windows Server page sends subscription customers to the ESU terms, so the Arc rule may carry across through the subscription's equivalent rights, but Microsoft never makes that connection explicit. Microsoft allows an active MCA subscription to qualify for ESU, but it has not expressly attached the new Arc condition to that subscription.

One organisation may therefore use no-cost Azure virtual-machine coverage for an older release, paid monthly coverage through Azure Arc and traditional annual ESU licences at the same time. All three routes can deliver security updates, but their prices, billing methods and Software Assurance requirements differ.

Microsoft 365 Copilot eligibility for government plans

Microsoft has added four government plans to the Microsoft 365 Copilot licence prerequisite table: Microsoft 365 G3, Microsoft 365 G5, Office 365 G3 and Office 365 G5. A user assigned one of those licences can now satisfy the Product Terms' base-licence requirement for Microsoft 365 Copilot without also needing a separate commercial-plan prerequisite.

Microsoft's Microsoft 365 Copilot licensing documentation already listed these plans and described Copilot availability in the US Government Community Cloud, GCC High and Department of Defense environments. The service documentation had therefore moved ahead of the contractual prerequisite table. The August update brings the two into line by adding the same four plans to the Product Terms.

Microsoft's government cloud offers are currently limited to eligible United States government organisations and qualifying partners, according to its government product page. Within that scope, the new row confirms which subscription can provide the base licence for the Copilot add-on. Feature availability, release timing and deployment requirements can still differ among GCC, GCC High and DoD, so those questions remain separate from the licence prerequisite Microsoft has updated.

Customer Copyright Commitment and configurable metaprompts

Microsoft's Customer Copyright Commitment is a promise to defend customers against certain third-party intellectual property claims involving output from a Covered Product. The promise comes with conditions: customers must use the filtering and safety systems built into the product, leave those safeguards in place and meet additional requirements covering their input, deliberate infringement and any metaprompts they can configure.

One metaprompt rule now covers every Covered Product

The fifth condition in the Universal Licence Terms for Online Services used to name Azure OpenAI in Microsoft Foundry Models alongside any other Covered Product with configurable metaprompts or safety systems. In August, Microsoft removes the product name and uses one rule for every Covered Product with these configurable controls: the customer must implement all safeguards listed on Microsoft's Customer Copyright Commitment Required Mitigations page for the product that produced the disputed output.

A metaprompt is an instruction that helps govern how a model responds before it processes an end user's prompt. Some Microsoft products let customers change this instruction layer or other safety controls, giving them more influence over the resulting output. The condition applies because those controls can be configured, whether or not the customer changes them. Microsoft makes its copyright defence dependent on the customer using the safeguards published for that service. The August sentence begins by identifying configurable metaprompts or safety systems as the feature that triggers the condition, then sends every affected product to the same list.

Microsoft publishes the required safeguards separately

The linked page currently gives separate requirements for Azure OpenAI, Microsoft Copilot Studio and GitHub Copilot. It also explains that Copilot services with fixed safety systems require no extra customer steps under this condition. Where Microsoft fixes the safety systems, the customer has nothing extra to configure. Where the controls are configurable, the published requirements can affect the protection even if the customer leaves the default settings unchanged.

Because Microsoft keeps these requirements on a separate page, they can change without a corresponding sentence changing in the Product Terms. For an existing service, Microsoft generally gives customers six months to implement a new or changed safeguard. For a new service, feature or use case, the requirement can apply as soon as that capability becomes available. To determine whether a particular output is protected, a customer may therefore need both the Product Terms and the version of the safeguards that applied at the relevant time. The Product Terms contain the condition, while the linked page supplies the configuration steps and transition periods. A setup that met the published requirements when it was deployed may need to change later even when the Product Terms themselves stay the same.

The August wording follows the June Copilot Studio change

The Glossary also changes the definition of a Covered Product. It used to refer to an eligible Azure OpenAI model or "Copilot"; it now says "any Copilot". The extra word does not name a newly protected product or change the other conditions of the commitment. It brings the definition into line with the product-neutral wording of the revised metaprompt condition.

Microsoft added Copilot Studio as a Covered Product in June 2025. Until June 2026, the MCA and EA/EAS Power Platform entries also contained a dedicated clause stating that Copilot Studio was a Covered Product with configurable metaprompts or other safety systems. Microsoft removed that clause from both programme views on 1 June 2026. It did not replace the clause with an exclusion or say that Copilot Studio had ceased to qualify.

Copilot Studio remains on Microsoft's required-mitigation page, which describes it as one of two services with configurable safety systems and sets out a service-specific safeguard. This supports the view that qualifying Copilot Studio output can still fall within the commitment when the general Covered Product definition is met and the customer follows that safeguard. The route is simply less explicit than it was: the product-specific confirmation has gone from the MCA and EA/EAS entries, while the separate mitigation document continues to treat Copilot Studio as a service to which the commitment can apply.

Microsoft describes the August Universal Terms edit as a minor clarification to responsible-use language. The wording is cleaner, but the change appears inside the Customer Copyright Commitment and directs the reader to a separate list of safeguards. Anyone checking whether a particular output is protected must now read both sources.

Scope of Azure service retirement notices

Microsoft still promises at least 12 months' notice before it retires an Azure service or removes a material part of one. The August Azure Product Terms do not change that period, but they are more precise about what the promise covers. The earlier sentence referred to removing "any material feature or functionality" or discontinuing "a service". It now refers to discontinuing a "Microsoft Azure Service" or removing a material feature or functionality "of that Microsoft Azure Service". The added words tie the feature directly to the Azure service named in the terms.

The narrower wording becomes important when Microsoft retires a capability that customers use with an Azure service but that Microsoft does not classify as part of the service. A material feature of the service remains within the 12-month commitment; documentation, an integration or a separately offered capability could fall outside it if Microsoft treats it as something distinct. The exceptions remain the same: Microsoft may act sooner for security, legal or system-performance reasons, and the notice promise does not apply to previews. Microsoft describes the rewrite as a clarification, which is reasonable because the notice period and exceptions have not changed. If Microsoft removes a capability after August, however, the 12-month promise will apply only if the capability is material and Microsoft treats it as part of the Azure service rather than something offered alongside it.

Defender Experts product name changes

Microsoft has renamed much of the Defender Experts family. The August changes are easier to follow side by side:

Sources: product names: Microsoft Product Terms, August changes and Microsoft Defender Experts Product Terms; promotion label: Microsoft Product Terms, Promotions.

MDR and Hunting describe the work

The change from XDR to MDR is the least mysterious of the renames. Microsoft Defender XDR remains the underlying security platform, while Defender Experts MDR is the Microsoft-delivered service that monitors, investigates and responds to incidents on that platform. Microsoft has not published a reason for the change, but managed detection and response describes the work more directly and avoids giving the service and the platform almost the same name.

Removing "for" and "XDR" from Defender Experts Hunting follows the same logic. Microsoft's Defender Experts overview describes proactive hunting across endpoints, identities, email, cloud applications and cloud workloads, so the shorter name follows the work Microsoft performs instead of tying the service to one platform label. The extra "s" added to the promotion label simply brings it into line with the Defender Experts family name; the Product Terms show no related commercial change.

Why one suite is "for Unified customers"

The Suite renames are harder to understand because P1 and P2 were two different packages, and the new names conceal that relationship unless their components are placed side by side. Microsoft's current suite comparison shows what each package contains:

Source: Microsoft Defender Experts services comparison.

Microsoft has not brought these pieces together in one explanation, so the logic has to be reconstructed from the component table and its published service documents. Those sources show how the packages are built, but they do not publish the sales rule for the renamed plan.

Microsoft Unified Enterprise is Microsoft's organisation-wide enterprise support offering. Its foundational services include success management through a Customer Success Account Manager, problem resolution and escalation support, advisory help, training and assessments across the customer's Microsoft estate. The longer name in the final row, Microsoft Unified Enterprise for Defender Experts Suite, brings the same kind of support into a much narrower setting. Microsoft's Defender Experts Services Description says that these support services are included when Defender Experts Suite is purchased through an Enterprise Agreement or Microsoft Customer Agreement, and limits them to the Microsoft Security Cloud products the customer has purchased.

If Microsoft Unified Enterprise for Defender Experts Suite were another product that had to be bought first, the two names would describe a circular purchase. Microsoft does not document it that way. The service description treats the Defender-specific support as part of the Suite purchase, while the Product Terms list only two Suite User Subscription Licences and no third licence for the support component. The component sits inside the plain Microsoft Defender Experts Suite; it is not a preliminary licence for the version "for Unified customers".

An organisation covered by Microsoft Unified Enterprise already has the broader support foundation across its Microsoft estate. Microsoft's package design therefore leaves the narrower, security-only version out of former P1, which supplies Defender Experts MDR, Cybersecurity Incident Response and Enhanced Designated Engineering and is now called Microsoft Defender Experts Suite for Unified customers. Former P2 also includes the Defender-specific Microsoft Unified Enterprise component and becomes the plain Microsoft Defender Experts Suite.

The comparison does not tell us whether Microsoft will refuse an order for the version "for Unified customers" from a buyer that does not already have Microsoft Unified Enterprise. The Product Terms prerequisites are the same for both packages: the customer needs the same qualifying Microsoft 365 or Defender licences and must buy at least 1,500 Suite licences. An active Microsoft Unified Enterprise agreement does not appear in the prerequisite table, and none of the other public documents says whether or how Microsoft checks a buyer's status when an order is placed. On the public evidence, the qualifier identifies the intended customer; it is not a stated Product Terms prerequisite.

Old and new Defender Experts Suite names will continue to meet in quotations, approvals and renewal workbooks. P1 maps to Microsoft Defender Experts Suite for Unified customers, while P2 maps to the plain Microsoft Defender Experts Suite. An approval written for P1 cannot be cleaned up simply by deleting "P1" and substituting the plain name. Doing so would relabel the old P1 package as the successor to P2 and suggest that the additional support component was included.

The rename sits on top of the earlier naming cycle we described when Microsoft 365 E5 Security and E5 Compliance became the Defender and Purview suites. Those newer Suite names now appear as prerequisites for Defender Experts products that have themselves been renamed. Teams maintaining architecture documents, service descriptions, invoices and internal chargeback records will have to reconcile both generations of names, so the P1 and P2 crosswalk will remain useful long after the Product Terms page has moved on.

Services Provider Use Rights remain unchanged

The Services Provider Use Rights, which govern products licensed through the Services Provider License Agreement (SPLA), have not changed since 6 May 2026. That release extended the restriction on using output from robotic process automation and unattended software to train AI models across the relevant Office Suites, Project and Visio provisions. We covered the change in the June Product Terms update. The current SPUR remains dated 6 May, so there is no new August SPUR wording to interpret.

Get in touch

Microsoft's Product Terms change frequently, and the practical effect is not always obvious from the change summary. If you need help understanding how the August update affects your organisation, get in touch. We don't sell Microsoft licences or cloud services, so our advice is independent.