Secure Authentication (WSA) Partner Guidance

Work or School Account (WSA) / Microsoft Entra ID enforcement

is now a leading cause of escalations on Volume Licensing transactions. With Q4 close approaching and a high volume of June Enterprise Agreement (EA) renewals, extensions, and amendments in flight, missing or misaligned WSAs are the single most common reason transactions land in hold queues. This article gives partners a concise readiness playbook, the validation steps to run before submission, and the customer-facing templates and FAQ you need to drive WSA conversations early.

Important

WSA issues identified late in the cycle are a leading cause of Q4 close slippage on June EA deals. Confirm WSA validity before you submit any renewal, extension, amendment, or manual enrollment form.

Latest Improvements for WSA Validation in VL Central (May 2026)

Based on Partner feedback and concerns about the impact on customer sales, Microsoft is implementing improvements in Volume Licensing Central (VLC) Contracts related to Secure Authentication (WSA) requirements. These updates reduce the risk of WSA-related delays for EA agreements. Two of these improvements are already active (since 22 May 2026), and two more go live on 29 May 2026.

1. Clearer WSA Validation Error Messages

What Changed: When a partner or Microsoft processing team validates a contact’s WSA ID in VL Central Contracts, the system now provides explicit results that separate different causes of failure. In prior releases, the generic “invalid WSA ID account” error message lacked detail. From May 29, the validation result will distinctly indicate if:

  • No Work or School Account exists for the entered email (meaning the email is not a valid WSA in Microsoft Entra ID).

  • The WSA’s cloud scope is misaligned with the customer PCN cloud-scope environment (e.g. a Government WSA entered for a Commercial enrollment, or vice versa).

Benefit: These clearer messages remove ambiguity between partners, operations and end-customers. Partners will know immediately whether to advise their customer to create a WSA for the contact or to ensure the WSA is under the correct Commercial/Government cloud. This reduces the need to escalate to Microsoft support simply to diagnose errors in up to, saving time and avoiding delays.

Timeline: The enhanced error messaging will roll out globally on 29 May 2026. After this date, partners using the Add-Contact+“Validate” button in VLC Contracts will see the new, detailed messages.

2. Reduction in MBSA level WSA holds on EA Agreements

What Changed: Certain EA agreements experienced a hold situation in relation to contacts used for the creation of the MBSA (Microsoft Business and Services Agreement).

Benefit: Process and system improvements leading to a significant reduction of WSA related holds for contacts on the MBSA agreement level.

Timeline: This fix is already active as of 22 May 2026. Partners should already experience fewer WSA-related holds related to MBSA contacts.

3. Reduction in holds for cross-cloud - Multi-Tenant EA Enrolments (US Commercial vs Government Cloud-Scope)

What Changed: In multi-tenant EA scenarios – particularly where one EA’s lead enrollment is in a different cloud environment than one of its related tenants/child (billing) enrollments – partners can expect a reduction in holds and faster resolution.

Benefit: This process and system improvement addresses a major source of quarter-close friction: “lead vs billing tenant” cross-cloud WSA issues for US Customers who use both Commercial and Government cloud-scope offerings.

Timeline: This improvement was implemented on 22 May 2026. Multi-tenant EA packages created after this date benefit from the new streamlined validation.

4. Improved Handling of “Tenant Sub-Scope” for Cloud Scope Alignment

What Changed: The contract system now more intelligently handles sub-scope details for customer tenants during EA contract setup, particularly for Azure and multi-cloud scenarios caused by missing internal tenant identifiers or mismatches in cloud scope tracking, even when the WSA information was correct.

Benefit: Fewer WSA validation holds. Partners will see improved reliability when working on EA agreements involving complex tenant configurations, especially for Azure accounts or AOS-G enrolments that experienced WSA validation errors if not all tenant data was perfectly aligned.

Timeline: This update is set to deploy on 29 May 2026.

Ongoing Work & Future Updates

Microsoft continues to monitor WSA-related issues and partner feedback and is exploring further enhancements. Additional improvements beyond these four are under consideration. The immediate focus, however, is to ensure these four changes effectively support May–June EA deal closures and restore confidence in the process.

What Has Changed and Why It Matters Now

Under Microsoft's Secure Future Initiative (SFI), Microsoft requires Work or School Accounts (WSAs) — organization-managed identities in Microsoft Entra ID (formerly Azure AD) — for key Volume Licensing roles. Personal Microsoft accounts (MSA / Live IDs) are no longer accepted.

This requirement applies across:

  • Enterprise Agreement (EA / EAS)
  • Server & Cloud Enrollment (SCE)
  • AOS-G (Agreement for Online Services – Government)

There is no SLG/AOS-G exemption from WSA or cloud-scope enforcement. With June EA volume concentrated in the final weeks of Q4, even small validation gaps translate directly into delayed license delivery, customer escalations, and missed close dates.

WSA Requirements at a Glance

Before submitting a renewal, extension, amendment, or manual enrollment form, confirm that your customer's key licensing contacts:

  • Use a Work or School Account (organization-managed, not a personal email)

  • Are aligned to the customer's tenant and cloud environment (Commercial vs Government) also referred to as Cloud-Scope

  • Are current and active users (not legacy or inactive accounts)

WSA is mandatory for:

  • Notices Contact (NTC)
  • Online Administrator

WSA is recommended (not mandatory) for:

  • Online Service Manager (OSM)

All other legacy contact roles — Bill-to Contact, Key Viewer, License Position Viewer, Online Admin, Downloads, and Software Assurance Manager — no longer auto-provision access in the Microsoft 365 Admin Center. Customers must now assign these roles directly via self-service in the Microsoft 365 Admin Center using WSAs.

Cloud Scope Alignment (Critical for SLG / Government)

A WSA that is valid in the wrong cloud will still fail validation. WSA identities must be created in the same cloud environment as the customer's Enrollment or PCN.

Customer cloud Acceptable WSA
Commercial (Public) Commercial WSA
Commercial (Public) using GCC products Commercial WSA
Government (for GCC High / Azure Gov) Government WSA
Government (for DoD) Government WSA

For SLG and government customers:

  • A Commercial WSA cannot access GOV - GCC High, or DoD agreements

  • Cross-cloud WSAs will be rejected

This enforcement protects data sovereignty, tenant isolation, and compliance for government workloads.

Mitigating Q4 Close Risk on June EA Deals

The single highest-leverage action you can take this quarter is to confirm WSA validity upfront, before the customer signs off and well before submission. Common breakdowns we are seeing:

  • A WSA has not been set up for the named contact
  • The WSA does not match the customer's cloud environment (Commercial vs Government)
  • A typo, alias, or outdated email is provided
  • The WSA belongs to a tenant that has been deleted or no longer exists

Each of these issues drops the transaction into a processing hold and requires you to re-engage the customer, costing days you may not have in late June.

Recommended partner cadence for June EA close:

  1. Identify every June-dated renewal, extension, and amendment in your book of business
  2. Confirm proposed Notices Contact and Online Administrator emails with the customer in writing
  3. Validate each WSA in VL Central before package submission (see next section)
  4. For any failed validation, route the customer to their IT administrator immediately
  5. Pause submission of any manual enrollment form until WSA compliance is confirmed

Primary Validation Method — Validate WSA in VL Central

The Validate WSA feature in VL Central confirms cloud type early, without committing the contact to the package.

  1. Go to VL Central → Contracts

  2. Create or edit a contract package

  3. Select Add Contact or Edit Contact

  4. Enter the email address you want to check/validate

  5. Select Validate Button

The system confirms whether the email is a valid Work or School Account in the correct cloud scope without adding it to the package. Use this for both NTC and Online Administrator contacts before submission.

Secondary Validation Method — Sign-in Check

If you need a quick secondary check (for example, when the customer cannot wait for VL Central access), have the contact attempt to sign in at the portal that matches the customer's cloud:

Cloud scope Validation sign-in URL
Commercial / GCC https://admin.microsoft.com
GCC High / Azure Gov https://portal.office365.us
DoD https://portal.apps.mil

How to interpret the result:

  • If the sign-in prompts for a Work or School account (or redirects to an org login) → valid WSA, good to go
  • If the sign-in redirects to a Microsoft Account (Live) or says the account doesn't exist → not a WSA, needs to be set up

This is also a useful alternative sign-in for users who did not receive the welcome email if the Azure AD identity is not mailbox-enabled.

Manual Enrollment Form Submissions — Partner Responsibility

This guidance applies when you submit an enrollment or amendment using a manual form on behalf of the customer.

Warning

Manual forms allow entry of non-WSA emails — but backend systems will reject them. Validation is your responsibility. Backend enforcement cannot be bypassed.

Who does what

Role Responsibility
Partner Completes and submits the manual enrollment form; validates WSA compliance before submission
Customer Owns and provides the correct WSA email identity
Customer IT Admin Creates or configures the WSA if one does not already exist

Required before form submission

A WSA / valid email address is mandatory for all enrollments. Failure to meet this requirement may result in processing delays and rework.

  • The email address entered on the form must be a valid Work or School Account
  • Personal, unmanaged, or consumer emails are not supported
  • Partners cannot create, convert, or correct WSAs on the customer's behalf
  • Partners cannot bypass or override WSA enforcement

Step-by-step process

1. Collect customer contact details

Before completing the form, confirm with the customer:

  • Primary contact email address
  • Confirmation that the email is a valid WSA

If unsure, the customer must confirm with their IT administrator before proceeding.

2. Validate WSA compliance

  • Do not submit the manual form until WSA compliance is confirmed
  • Verify the WSA in VL Central: open any package or create a draft package → go to Add contact → enter the WSA → click Validate
  • Manual forms do not block non-WSA entries, but backend systems will

3. Customer action if the WSA is not valid

The customer works with their IT administrator to:

  • Create or enable a Work or School Account
  • Ensure it is properly configured in their Microsoft tenant

Only after the WSA is in place should you continue with submission.

4. Submit the manual form

Once WSA compliance is confirmed:

  • Enter the verified WSA email in the required contact fields
  • Complete all remaining enrollment information
  • Submit the form through the standard manual process
  • The Welcome Letter is sent systematically to the WSA email address — confirm the customer has it set up as an active mailbox
  • If the Welcome email is not received, use the Microsoft 365 admin center for volume licensing sign-in link as an alternative

What happens if the WSA is not valid

  • Enrollment is placed on hold by OSC Processing
  • You are notified to correct the issue
  • You must re-engage the customer
  • Processing resumes only after a valid WSA is provided
  • The WSA must align with the PCN Cloud Scope (Commercial vs Government) — even a valid WSA causes a processing hold if it does not match the PCN cloud scope

Key reminders

  • Manual forms allow entry of non-WSA emails — validation is your responsibility
  • Backend enforcement cannot be bypassed
  • Early WSA validation prevents hold queues, customer frustration, quarter-close delays, and repeated rework

Best practice

  • Confirm WSA validity upfront — the earlier the better
  • Pause submission if anything is unclear
  • Direct the customer to their IT admin early

What to Expect from Your Microsoft Contacts

As part of the Q4 close push, your Microsoft account teams, commercial executives, and partner development managers will be proactively reaching out to flag WSA readiness on upcoming renewals, extensions, and amendments. The template below shows the form this communication is likely to take. If you receive a note like this, treat it as a heads-up that the named transaction is at risk and act on the WSA checks immediately.

Subject: Action Required: Confirming Work or School Accounts (WSAs) for Your Upcoming Renewal

Hi [Partner Name],

As we prepare for your upcoming [renewal / extension / amendment], I wanted to highlight an important requirement to help ensure a smooth and timely process.

Microsoft now requires Work or School Accounts (WSAs) for key licensing roles as part of enhanced security standards. This applies across both EA and non-EA agreements.

To proceed without delay, please confirm that your key licensing contacts:

  • Use a Work or School Account (organization-managed, not a personal email)
  • Are aligned to your tenant and cloud environment (Commercial vs Government)
  • Are current and active contacts (not legacy or inactive users)

WSA is mandatory for the Notices Contact and Online Administrator roles. WSA is recommended (not mandatory) for the OSM (Online Service Manager) role.

Issues with WSAs can lead to delays in receiving licenses as expected. This most commonly occurs when a WSA is not set up, or when the WSA does not match the correct cloud environment (Commercial vs. Government).

To move forward, please:

  1. Share the email addresses for your proposed licensing contacts
  2. Confirm they are organization-managed accounts (WSAs)
  3. Confirm the WSA is aligned to your tenant / cloud environment

I'm happy to review and validate that the email aligns to a valid WSA and the correct cloud environment prior to submission.

Thank you, [Microsoft CE / AE / PDM Name]

Customer Email Template — For Partner Use

Use the template below when reaching out to your customer to collect and confirm WSA details for an upcoming licensing action. Adjust the bracketed fields as needed.

Subject: Action Required: Confirm Work or School Accounts for Upcoming Licensing Action

Hi [Customer Name],

As we prepare for your upcoming licensing action [renewal / extension / amendment], we want to highlight an important Microsoft security requirement to help ensure timely and smooth processing.

Microsoft now requires that key licensing contacts use a valid Work or School Account (WSA) aligned to your tenant and cloud environment (Commercial or Government). Missing or misaligned WSAs can result in processing delays or holds.

Please confirm your proposed licensing contacts:

  • Use an organization-managed Work or School Account (not a personal email)
  • Are active and current users
  • Are created in the correct cloud environment for your agreement

Work or School Accounts are required for the following roles:

  • Notices Contact
  • Online Administrator

WSA is recommended (not mandatory) for the OSM (Online Service Manager) role.

To move forward, please reply with:

  1. The email addresses of your proposed licensing contacts
  2. Confirmation that each is a valid Work or School Account
  3. Confirmation that each is aligned to the correct cloud environment

If helpful, we're happy to validate the accounts with you before submission to avoid any delays.

Thank you for your partnership — please let us know if you have any questions or need assistance.

Frequently Asked Questions

What has changed in contact management for customers?

Microsoft now requires Work or School Accounts (WSA / Microsoft Entra ID) for key Volume Licensing roles under the Secure Future Initiative (SFI). This improves identity security and auditability and ensures role-based access is properly controlled.

Which agreements are impacted?

These requirements apply to all Volume Licensing programs, including:

  • Enterprise Agreement (EA / EAS)
  • Server & Cloud Enrollment (SCE)
  • AOS-G (Agreement for Online Services – Government)

There is no SLG / AOS-G exemption from WSA or cloud-scope enforcement. Confirm WSA setup in advance of quarter close to support prompt processing.

What is a Work or School Account (WSA)?

A Work or School Account (WSA) is an organization-managed identity in Microsoft Entra ID (formerly Azure AD), such as user@agency.gov or user@contoso.com. Personal Microsoft accounts (MSA / Live IDs) are not permitted for Volume Licensing access.

Which roles require a WSA?

WSA is mandatory for the Notices Contact (NTC) and Online Administrator roles. All other legacy contact roles no longer receive automatic admin access.

What happened to legacy Volume Licensing contact roles?

The following roles no longer auto-provision access in the Microsoft 365 Admin Center:

  • Bill-to Contact
  • Key Viewer
  • License Position Viewer
  • Online Admin
  • Downloads
  • Software Assurance Manager

Customers must now assign roles directly via self-service in the Microsoft 365 Admin Center using WSAs.

What does "cloud scope" mean?

Cloud scope refers to the Microsoft cloud environment where the customer operates — Commercial (Public) or Government (GCC, GCC High, DoD). WSA identities must be created in the same cloud environment as the customer's Enrollment or PCN. If the WSA does not match the cloud scope of the Enrollment, it will be rejected by Microsoft systems.

Why is cloud scope especially important for Government Cloud?

For SLG and government customers:

  • A Commercial WSA cannot access GCC, GCC High, or DoD agreements
  • A GCC WSA cannot access GCC High or DoD agreements

This enforcement protects data sovereignty, tenant isolation, and compliance for government workloads.

What causes an "Invalid WSA Account ID" error?

Common causes include:

  • The email is not created in Microsoft Entra ID
  • The WSA exists in the wrong cloud (Commercial vs GCC / GCC High / DoD)
  • A typo, alias, or outdated email address
  • A WSA associated with a tenant that has been deleted or no longer exists

These are identity or cloud alignment issues, not system defects.

What if a customer does not have Microsoft Entra ID today?

The customer can:

  • Create a free Microsoft Entra ID tenant at https://signup.microsoft.com
  • Create WSAs for the required contacts
  • No Microsoft 365 licenses are required

Does this apply to AOS-G and air-gapped government environments?

Yes.

  • WSA requirements apply fully to AOS-G
  • Cloud scope alignment is mandatory for GCC, GCC High, DoD, Azure Secret, and Azure Top Secret
  • Only WSAs created in the correct government cloud will validate
  • Cross-cloud WSAs will be rejected

What should partners emphasize to customers?

Frame the WSA requirement as a positive security change designed to protect Microsoft customers — not as a Microsoft-imposed obstacle. Position it as part of the same identity and compliance posture customers already expect for their tenant.

What is the primary WSA validation method partners should use to mitigate holds or breaks?

Use the Validate WSA feature in VL Central to confirm cloud type early:

  1. Go to VL Central → Contracts
  2. Create or edit a contract package
  3. Select Add Contact or Edit Contact
  4. Enter the email address
  5. Select Validate

Ensure NTC and Online Administrator contacts have valid WSAs in the correct cloud. The system confirms whether the email is a valid Work or School Account in the correct cloud scope without adding it to the package.

Are there any additional validation best practices?

As a secondary option, use a sign-in check at the portal that matches the customer's cloud (see Secondary Validation Method above). If the sign-in prompts for a Work or School account, the identity is valid. If it redirects to a Microsoft Account (Live) or reports that the account doesn't exist, the WSA needs to be set up.

Is a credit card needed to set up a tenant or trial? Is there another way to create an identity tenant without ordering a trial?

A Microsoft Entra ID tenant can be created at no cost and without a Microsoft 365 license. Additional guidance is pending and will be added to this article as it becomes available.

Secure Authentication (WSA ID), Role Segregation, COCP (EA), Cloud Scope – Guidance & Resources for LSP, SSP, AOS-G Partners (March 2026 Article on What's New)

  • Date: March 24, 2026
  • Partner Types: LSP | SSP | EDA | AOS-G
  • Programs: EA | EAS | SCE | AOS-G

Microsoft has implemented Work or School Account (WSA) security requirements as part of the Secure Future Initiative (SFI) to strengthen identity protection and role management across Volume Licensing programmes. Since January 15, 2026, WSA IDs (Microsoft Entra accounts) are mandatory for specific contract roles on EA, EAS, SCE, and AOS-G agreements.

These changes coincide with the rollout of customer-initiated Change of Channel Partner (COCP), MAC role segregation, and cloud scope enforcement, creating a convergence of launches that has generated significant partner queries.

Common Issues – Partner Q&A

What is a Work or School Account (WSA), and why is it now required?

What it is: A Work or School Account (WSA) is an organisational account managed in Microsoft Entra ID (formerly Azure Active Directory). It typically takes the form of user@company.com or user@company.onmicrosoft.com, managed by the customer's IT department.

Why it's required: As part of Microsoft's Secure Future Initiative, WSA enforcement ensures that only verified, organisation-managed credentials are used to access Volume Licensing assets and admin roles. This reduces the risk of unauthorised access from compromised personal accounts (Microsoft Accounts/MSAs) and provides a clear audit trail for role assignments.

Which roles require WSA:

  • Notices Contact (NTC): Mandatory WSA. This contact receives the VL Administrator role on the Microsoft 365 Admin Centre (MAC).

  • Online Service Manager (OSM): WSA required to receive the OSM role on MAC upon agreement activation (effective January 15, 2026).

All other legacy contact roles (Bill-to Contact, Key Viewer, License Position Viewer, Online Admin, Downloads, Software Assurance Manager) no longer receive automatic MAC roles. Customers must now assign these roles via self-serve in the Microsoft 365 Admin Centre.

Resources:

We are seeing an "Invalid WSA Account ID" error in VL Central. What does this mean?

The error “Invalid WSA Account ID” indicates that the email entered is not recognized as an active Work/School Account in the expected tenant or cloud. Common causes include:

  • Email not in Azure AD: The email address is not associated with any Azure AD account. In other words, the contact hasn’t been set up in Microsoft Entra ID.

  • Wrong cloud/tenant: The email might exist in Azure AD but in a different tenant or cloud than the one tied to the customer’s enrollment. For example, using a Commercial cloud email for a GCC High customer will fail validation (and vice versa).

  • Typo or old info: Sometimes it can be as simple as a typo in the email or using an alias instead of the user’s primary login ID.

How to resolve it:

Tip

Validate using VL Central: Partners can confirm WSA validity by going into VLC Contracts, editing or creating a package, and using the “Add Contact” -> Validate feature. Input the email and click the blue Validate Button – the system will confirm if it’s a valid WSA or not (without actually adding it to the package). This is a quick way to test if a customer-provided email will pass the requirement.

  • Validate using VL Central: Partners can confirm WSA validity by going into VLC Contracts, editing or creating a package, and using the “Add Contact” -> Validate feature. Input the email and click Validate – the system will confirm if it’s a valid WSA or not (without actually adding it). This is a quick way to test if a customer-provided email will pass the requirement.

  • If not valid – ask customer’s IT to create/confirm the account: In most cases, the fix is to have the customer’s IT admin either create a new Azure AD user for that email or provide an alternate email that is already in their tenant.

  • For example, if denverwater.org is the customer domain and “john@denverwater.org” comes up invalid, the customer’s Entra admin should ensure John has an Entra ID account (under denverwater.org tenant) with that email UPN. Once created and licensed (it can even be a free Azure AD account), that email will become a valid WSA.

  • It’s key that the account is created in the correct cloud: e.g., GCC High customers may need the contact’s identity in a GCC High tenant.

  • Double-check the cloud alignment: If the customer operates in a sovereign cloud (Government, Germany, etc.), ensure the WSA is also in that cloud environment. An account in a Commercial tenant won’t meet a GCC customer’s WSA requirement.

  • Typos and domain fixes: Make sure the email domain is exactly the one tied to the Azure AD. Sometimes customers use vanity domains; ensure the domain is registered in their tenant.

Tip

If partners or customers want an out-of-band way to confirm WSA IDs, they can ask the user to try logging in at office.com or https://admin.microsoft.com with that email: If it prompts for Work/School account and possibly accepts a password or redirects to their own organizational login, then it’s likely a WSA.
If it says “This account doesn’t exist” or goes to a Microsoft Account (Live login) screen, it’s not yet an Entra/Azure AD account.

Bottom line: Work closely with customers’ IT admins to get valid WSA emails for all required contacts before finalizing the contract. This avoids last-minute delays.

What is "cloud scope," and why does it matter for WSA validation?

What is cloud scope: Cloud scope refers to the Microsoft cloud environment where a customer or partner operates: Commercial (Public), Government Community Cloud (GCC), GCC High, or DoD.

Starting July 23, 2025, Microsoft enforced cloud scope validation at the PCN level for EA contracts. WSA accounts must exist in the same cloud environment as the customer's tenant and contract.

Why it matters: A WSA from a Commercial cloud tenant cannot be used on a GCC High contract, and vice versa. If there is a cloud scope mismatch, the system will reject the WSA as invalid even if the account itself is legitimate.

How to avoid cloud scope errors:

  • Confirm the customer's cloud environment before providing contact information.

  • For US-only customers transacting in both Commercial and US Federal/GCC/Fairfax/Gov cloud scopes: Separate PCNs are required for each cloud scope (since January 23, 2025).

  • Partners and customers accessing GCC High or DoD contracts must use WSAs from those specific cloud environments.

  • Customers can only access VL contracts on the same cloud as their Entra ID. Public/GCC users cannot access GCC High/DoD contracts, and vice versa.

Sign-in portals by cloud scope:

Resources:

My customer doesn't have a Microsoft Entra tenant or WSA accounts. What should they do?

Solution: Customers without an existing Microsoft Entra tenant can create a free tenant and provision WSA user accounts at no cost. This does not require purchasing Microsoft 365 subscriptions.

Steps for customers:

  1. Visit https://signup.microsoft.com to create a free Microsoft Entra ID tenant.
  2. Create user accounts for the individuals who will serve as Notices Contact and Online Service Manager on the Volume Licensing agreement.
  3. Provide these WSA email addresses to the partner for use in VL Central Contracts.

Alternative for customers with Microsoft 365 or Azure: If the customer already uses Microsoft 365, Microsoft 365 Admin Centre, or Azure, they already have a Microsoft Entra tenant and can use existing WSA accounts.

Resources:

What happened to the legacy contact roles (Online Admin, Key Viewer, Downloads, etc.)?

What changed: As part of the MAC role segregation initiative, the following legacy roles no longer receive automatic MAC roles when listed on VL contracts:

  • Bill-to Contact
  • Key Viewer (KEY)
  • License Position Viewer (LPV)
  • Online Admin (OLA)
  • Downloads (DLD)
  • Software Assurance Manager (SAB)

What this means:

  • Partners can no longer use these roles in VL Contracts for new, renewal, extension, or CICR (Change of Contact Information Request) packages.

  • Partners cannot view users with MAC roles in VL Central.

  • Customers must now assign all MAC roles via self-serve in the Microsoft 365 Admin Centre.

Who still gets automatic roles:

  • Notices Contact (NTC): Receives VL Administrator role (with WSA).
  • Online Service Manager (OSM): Receives OSM role (with WSA, effective January 15, 2026).

How customers assign roles: VL Administrators can assign roles to users with WSAs via the Microsoft 365 Admin Centre under Billing > Your Products > Volume Licensing > Role Assignments > Manage VL role assignments.

Resources:

How does customer-initiated COCP work, and what do I need to provide to my customer?

What changed: Since November 2025, Enterprise Agreement (EA) and Enterprise Subscription (EAS) customers can initiate Change of Channel Partner (COCP) requests directly via the Microsoft 365 Admin Centre or Azure portal. The legacy partner-initiated COCP process in eAgreements (VLCM) has been retired as of February 2026 (read-only).

What partners must provide to customers:

  1. Partner Public Customer Number (PCN): The customer needs your PCN to initiate the COCP request. You can find your PCN in any existing contract in VL Central Contracts. (The PCN you are using for your EA business and have all your Users in VLC mapped against.)

  2. Partner Notification Contact Email: Provide a verified (=contact must exist in VL Central) contact email from your organisation. This ensures you receive automatic notifications about the COCP request. If the customer enters an unverified email, you may not receive notifications* and must rely on the customer to inform you outside the system. (*but you/your team will still see all new COCP requests in VLC Contracts "Requests" tab)

How the process works:

  1. Customer initiates COCP in Microsoft 365 Admin Centre or Azure portal, providing your PCN and notification contact.

  2. You (the new partner) receive a notification and must accept or decline the request in VL Central Contracts under Requests > My customer requests within 10 days.

  3. Once you accept, the customer is notified of the effective date.

Resources:

My customer is experiencing delays in processing due to WSA or cloud scope errors. How can I escalate?

Proactive steps to avoid delays:

  1. Validate WSA before submission: Use the "Validate WSA" feature in VL Central Contracts before submitting packages.

  2. Confirm cloud scope alignment with the customer before providing contact information.

  3. Educate customers early: Share the resources in this post (see "Resources for Customers" section below) as soon as you begin the contracting process.

If an error occurs:

For processing holds or case escalations: Open a case in VL Central under My Cases & Support > +New Case. Include:

  • Agreement number or package ID

  • Screenshot of the error message

  • Confirmation that the WSA has been validated using VL Central or the Entra admin portal

  • Confirmation of cloud scope alignment

  • For urgent deals and close scenarios: Clearly indicate the deal urgency and effective date requirements in your case description. Escalate (within escalation rules) if required.

  • Do not escalate readiness or education issues (e.g., customer doesn't understand WSA) to Tier 2 or Engineering. These should be resolved using the shared guidance and resources.

Resources:

Resources for Customers

Partners can share the following resources with customers to help them understand WSA requirements and how to manage roles in the Microsoft 365 Admin Centre.

Understanding WSA and Sign-In

Creating a Microsoft Entra Tenant (for customers without Microsoft 365)

Managing Roles in Microsoft 365 Admin Centre

Initiating Change of Channel Partner (COCP)

Clarification: AOS-G Authorisation Partners and AOS-G Program

WSA Requirements Apply Equally to AOS-G

All changes related to Work or School Account (WSA) requirements and MAC role segregation apply to the AOS-G (Agreement for Online Services – Government) programme and all AOS-G authorisation partners.

Key points for AOS-G partners:

  1. WSA is mandatory for Notices Contact (NTC) and Online Service Manager (OSM) on AOS-G enrollments, just as it is for EA, EAS, and SCE programmes.

  2. Cloud scope alignment is critical: AOS-G customers operate in government cloud environments (GCC, GCC High, DoD, Azure Secret, Azure Top Secret). The WSA accounts provided must exist in the same government cloud environment as the customer's tenant and AOS-G enrollment. Cross-cloud WSAs will be rejected.

  3. Role inheritance changes: Only Notices Contact (with WSA) receives the VL Administrator role, and Online Service Manager (with WSA) receives the OSM role. All other legacy roles (Online Admin, Key Viewer, etc.) no longer receive automatic MAC roles. Customer IT admins must assign roles via self-serve in the Microsoft 365 Admin Centre (government cloud instance).

  4. Tenant setup for AOS-G customers: AOS-G customers must have a Microsoft Entra tenant in the appropriate government cloud. For Air Gap environments (Azure Secret, Azure Top Secret), specific tenant provisioning and onboarding processes apply.

  5. Processing and validation: Use the "Validate WSA" feature (see Partner Q&A above) in VL Central Contracts when submitting AOS-G enrolments and amendments to avoid processing delays.

Resources Summary

General VL Central Readiness:

WSA and Role Management:

Customer-Initiated COCP:

Support and Cases:

Understanding WSA and Signing In:

Creating a Microsoft Entra Tenant:

Managing VL Contracts and Roles:

Initiating Change of Channel Partner:

Cloud Scope and Government Cloud:

Microsoft Entra ID Documentation:

VL Central Training and Enablement:

  • Last updated on