Microsoft has confirmed that its Volume Licensing Contract Management (VLCM) portal will become read-only for customers on non-Enterprise Agreement programs starting July 24, 2026. The change, which shifts all downloads and key management to the Microsoft 365 admin center, won’t delete your ISO files or revoke license rights — but unprepared teams could find themselves locked out of critical deployment tools at the worst possible moment.
Where your Windows media and keys now live
The retirement of VLCM contract workflows doesn’t mean your volume-license software suddenly disappears. Microsoft’s documentation places all downloadable software and product keys firmly inside the Microsoft 365 admin center. The path is:
- Sign in with an approved licensing identity.
- Navigate to Billing → Your products → Volume licensing tab.
- Click View downloads and keys.
- Filter or search for the product you need, then examine its available downloads and keys.
It sounds simple, but the access model is granular in a way that often stumbles teams. Downloading an ISO or EXE installer requires either the VL Administrator or Product download manager role. Viewing or exporting product keys requires VL Administrator or Product keys reader. A person who can grab the Windows image may be unable to retrieve the activation key, and vice versa. In a mature environment, that’s least privilege working as designed. In an environment where access was handed out informally years ago, it’s an outage waiting to happen.
Microsoft originally pointed to July 10 as the read-only date but revised the timeline. July 24 is now the firm marker for non-EA contracts. Full decommissioning of the VLCM portal is scheduled by the end of July. An "August cutover" sometimes mentioned is actually the finale of a Microsoft launch series — not the retirement date itself. The distinction matters: contract management disruption and media access disruption are two separate operational risks.
The hidden time bomb: role assignments
When a deployment fails, the root cause is rarely a missing portal. Usually, it’s an unfulfilled assumption about who can get the bits. The most common mistakes I see:
- A single administrator holds all the keys — literally. If that person is on vacation, sick, or leaves, nobody can download a fresh ISO or retrieve a MAK.
- The person who handles imaging doesn’t have the right role in the admin center. They could always get VLCM downloads before, but now that path is closing and the M365 roles were never adjusted.
- Key management and media management were treated as one activity, not two. The CSV export of product keys is dumped in a shared folder or attached to a help desk ticket, creating an exposure that’s both a security risk and a licensing compliance headache.
Microsoft is explicit about what’s not changing: product keys facilitate activation, but they are not proof of a licensing position. Your entitlement evidence — License ID, organization name, product/edition, contract record — must live alongside the key. That’s an internal documentation task, not something the portal does for you.
Don’t panic-download — audit first
A bulk download of every ISO in sight feels productive. It’s not. An archived image you can’t trace to a license, a purpose, or an integrity check is a liability. Instead, run a tight deployment dependency audit:
- Inventory every offline Windows image used for provisioning, reimaging, lab rebuilds, repair, or disconnected environments.
- Note volume-license installers that accompany those images — especially any assumed during a bare-metal build.
- Identify every Multiple Activation Key (MAK), KMS client setup key, or other activation dependency baked into documented workflows. Do not paste the key itself into the build documentation.
- Map each dependency to its License ID and to a named owner who can confirm access is still valid.
- Locate deployment shares, imaging servers, removable recovery media, secure vaults, and automation scripts that contain or reference those media.
- Flag anything that depends on a personal browser download, an unmanaged file share, an ex-employee’s account, or undocumented credentials.
This exercise often reveals that the VLCM retirement is a forcing function, not a cause. A contract portal can become read-only without breaking a properly governed workflow. But it will expose that nobody assigned a durable VL Administrator, no break-glass access path exists, or the source of an old image is a mystery.
Build ironclad provenance records
For every ISO or EXE you keep, create a media record. At minimum:
- Product name, edition, language, architecture (when relevant)
- Date retrieved
- Download source (Microsoft 365 admin center, and which License ID it ties to)
- File size and storage location
- Owner and point of contact
- A cryptographic hash (SHA-256) calculated at acquisition.
Hashing is not a licensing control. It’s a provenance control. When an incident responder asks — “Is this the exact approved image we archived, or just a file with a familiar name?” — you have an answer. Verify that hash every time the image is copied to a deployment share or removable medium.
Treat customized images separately. If you modified Microsoft media with drivers, unattended files, or packages, retain the build procedure and reference to the original source. Without a repeatable build record, a custom image becomes impossible to refresh or defend as software ages and staff turns over.
Don’t rely on a general file share as your only archive. Maintain protected storage with write access controls, documented restore steps, and enough metadata for a different administrator to identify the correct file.
Test roles and restores before July 24
There are two phases to testing: access and result.
Access test: Assign a primary operational owner and a separate backup. The primary should hold only the minimum role needed for routine work. The backup must be able to step in for both downloads and key retrieval. Have the download-capable owner sign in and confirm that Billing → Your products → Volume licensing → View downloads and keys presents the expected products. Have the key-capable owner do the same and verify that License IDs and export capabilities are visible. Write a test record: date, account role, product tested, result.
Restore test: Retrieve one approved image from your archive. Compare its stored hash with a freshly computed one. Mount or otherwise validate the media according to your usual process. Check that the accompanying documentation identifies the correct product and license linkage. Do not wait for a disaster declaration to learn that a file is corrupt, inaccessible, or mislabeled.
Also, test the escalation path. If the key reader cannot access a needed License ID, or if the download manager cannot retrieve expected media, determine now whether the issue is internal role administration, entitlement visibility, or a Microsoft support matter. A cutover weekend is not the time to start troubleshooting.
Handle keys like the radioactive material they are
Keys are the most sensitive artifact you’ll handle. A CSV export is useful for reconciliation and recovery planning, but it can become an exposure if copied into ticket attachments, left in download folders, or shared freely.
Use the export to build or refresh your controlled key inventory, then handle the file as secret material. Limit access to staff who actually activate or recover systems. Record which License IDs are included. Do not distribute the raw export just because several teams touch imaging.
MAKs deserve extra attention in disconnected or remote deployment scenarios. They tend to be embedded in scripts that haven’t been reviewed in years. Confirm which workflows actually depend on them, whether the associated product is still part of your estate, and where the official activation process is documented. Remove stale key references as aggressively as you archive valid ones.
How we got here
Microsoft has been consolidating volume-license management into the Microsoft 365 admin center for several years. The VLCM portal was originally the hub for contract administration, software downloads, and key access. Then downloads and keys moved to the admin center, leaving VLCM for contract workflows. Now Microsoft is retiring those workflows for programs other than Enterprise Agreements.
The initial communicated date was July 10, but Microsoft revised it to July 24 for the read-only trigger. Full decommissioning follows by the end of the month. The August 11 event sometimes referenced is not a cutoff; it’s the final adoption call in Microsoft’s awareness campaign. Don’t confuse it with the operational deadline.
The practical effect is that you must be ready to operate entirely from the Microsoft 365 admin center for downloads and keys by July 24. The VLCM portal won’t vanish overnight, but it will stop accepting changes, and you won’t be able to rely on it for retrieval.
Your 8-point survival checklist
- Assign roles. At least two people need VL Administrator or Product download manager for media. At least two need VL Administrator or Product keys reader for keys. Separate the roles if your security model requires it, but ensure coverage.
- Verify access. Each assigned person logs into the admin center, navigates to Volume licensing, and confirms they can see downloads and keys for your contracts.
- Audit workflows. List every deployment, reimaging, repair, or recovery process that uses volume-license media or activation keys.
- Document provenance. For each approved image, record the hash, source, License ID, storage location, and owner.
- Secure keys. Export product keys once, store them in a credentialed safe, and map them to License IDs. Delete any stray copies.
- Run a restore test. Grab an image, verify its hash, mount it, and check the documentation.
- Test the emergency path. If the primary key reader is unavailable, can the backup retrieve the necessary keys? If not, fix it now.
- Repeat for offline and legacy systems. Disconnected environments and older Windows versions are often overlooked until an incident forces a rebuild.
What to watch next
After July 24, the VLCM portal will sit in read-only mode for some weeks before Microsoft removes it entirely. The August events are educational, not operational. Your long-term posture matters more than any single date: every Windows deployment should have a known media supply chain, a tested key retrieval path, and a documented restore procedure. Organizations that treat this transition as a process improvement will come out stronger. Those that assume everything will just keep working may find themselves staring at an error dialog when they can least afford it.
Microsoft’s documentation will continue to evolve, so book a recurring review of your media and key governance every quarter. The July 24 deadline isn’t an ending — it’s the moment your team proves it can stand on its own.