Intune Now Requires HTTPS for Win32 Apps: The Connected…

Start here — what this actually is

Since 16 June 2026, Intune only delivers Win32 app content over HTTPS. If you run Microsoft Connected Cache (MCC) — the free on-premises cache that keeps Win32 app and Teams content off your internet link — and its cache nodes were never configured for HTTPS, nothing visibly breaks. Devices still get their apps. They just silently stop using your cache node and pull straight from Microsoft's CDN instead, which quietly puts every Win32 app install back on your internet circuit.

This post is the full fix: exactly what changed, exactly which content is affected, and the complete certificate setup — CSR generation, signing, import, and validation — for both a standalone MCC node and a ConfigMgr-integrated one.

This is the quietest kind of outage: there's no error, no failed install, no ticket that points at the cause. Bandwidth usage just creeps up, Autopilot provisioning gets slower than it used to be, and nobody connects it back to a certificate that was never configured. If you deployed MCC at any point before this year, this is worth checking today.

The short version

As of 16 June 2026, Intune enforces HTTPS for all managed Win32 app content. Microsoft Teams content already required HTTPS and was never cacheable over plain HTTP either — so these are the two content families genuinely at risk. Windows feature/quality updates, Microsoft 365 Apps, Office Click-to-Run and Defender definitions are unaffected and keep working over HTTP. A standalone Connected Cache node needs a cache-node software version 2.0.0.2112 or later, a free port 443, and a TLS certificate in unencrypted .crt format — password-protected .pfx/.p12 files cannot be imported. The process is generate a CSR on the node itself, sign it with your own CA, then import the signed certificate back. A ConfigMgr-integrated Connected Cache node (on a distribution point) uses a different process entirely: enable TLS in IIS, then re-run the Connected Cache installer. Get either wrong and the failure mode is invisible — devices keep working, your cache just stops being used.

Who needs to read this

If you are…	What this means for you
Network / infrastructure engineer	If internet egress or branch-office bandwidth usage crept up with no obvious cause since mid-2026, check your MCC nodes' HTTPS status before chasing anything else.
Intune / endpoint engineer	Autopilot provisioning at remote sites getting slower with no policy change is the classic symptom — the cache is still "working," it's just not being used any more.
ConfigMgr admin running co-managed MCC	Your fix is different from a standalone node's — IIS binding plus a re-run installer, not the CSR/import workflow covered for standalone nodes.
Service desk / 1st line	No error ever surfaces to a user or an admin console for this — devices install apps successfully throughout, just more slowly and over the internet link instead of the local cache.

The problem: nothing breaks, your cache just stops being used

Microsoft Connected Cache exists to keep large, repeated downloads — Win32 apps most of all — off your internet circuit, by serving them from a local on-premises node instead of pulling every copy from Microsoft's cloud. It's free, and for any site with more than a handful of managed devices, it pays for itself quickly.

As of 16 June 2026, that stops working silently for any node that was never configured with a TLS certificate. Content delivery doesn't fail — the client simply falls back to the public Content Delivery Network and fetches the content directly over the internet instead. The install succeeds. The user never sees anything. What's gone is the bandwidth saving, the provisioning-speed improvement, and the localised delivery that justified deploying MCC in the first place.

⚠ Gotcha: the symptom shows up everywhere except where you'd look for it. Nobody files a ticket saying "my app install was slightly slower" or "our WAN link looks a bit busier than usual." This surfaces weeks later as a bandwidth or provisioning-time trend with no obvious trigger, and the actual cause — an unconfigured certificate on a cache node — is rarely the first thing anyone checks.

Organisations running Windows Autopilot at scale feel this hardest: Win32 app content is exactly what MCC was caching for new-device provisioning, so losing that cache quietly means slower provisioning and higher internet egress costs at every site that relies on it.

Why it happens: the HTTPS mandate, and what it does and doesn't cover

This isn't a Connected Cache change — it's an Intune content-delivery change that Connected Cache has to keep up with. Intune decided that managed Win32 app content must be delivered over HTTPS, full stop, and a cache node that can't speak HTTPS simply isn't eligible to serve that content any more. The client doesn't error out; it just treats the node as unavailable for that content type and goes to the CDN instead.

Two content families are genuinely affected, and the scope is narrower than it might sound:

Content type	Affected by this change?
Intune Win32 apps	Yes — HTTPS enforced from 16 June 2026. This is the change.
Microsoft Teams content	Already required HTTPS before this change, and was never cacheable on an HTTP-only MCC node. Worth checking at the same time if you haven't already.
Windows feature and quality updates	No — continues over HTTP through MCC
Microsoft 365 Apps / Office Click-to-Run	No — continues over HTTP through MCC
Defender definition updates	No — continues over HTTP through MCC

📋 Note: if your organisation doesn't use Microsoft Connected Cache at all, or you configured HTTPS on it when you first deployed it, none of this requires any action. This is specifically about nodes that have been running HTTP-only since before June 2026.

How to verify: is your cache node already affected?

Open the Azure portal and go to the Cache Node Management tab for your Connected Cache deployment.
Check the Software Version column for each node. HTTPS support requires version 2.0.0.2112 or higher — a node below that version needs reinstalling before HTTPS can be configured at all.
Check whether a certificate has ever been imported on each node. If you've never deliberately gone through a CSR/import process on a standalone node, or never touched IIS TLS binding on a ConfigMgr-integrated one, assume it's still HTTP-only.

Azure Portal — Cache Node Management

mcc-node-site01 v2.0.0.1980 — needs reinstall

mcc-node-site02 v2.0.0.2240 — eligible for HTTPS

The fix: configuring HTTPS, standalone and ConfigMgr-integrated

Before you start, on a standalone node

Confirm port 443 is free on the host — the cache needs to bind to it.
Confirm the exact hostname or IP address client devices use to reach the node. This has to match the certificate's Subject and SAN exactly.
If your network performs TLS inspection, exempt this node's traffic. Intercepted HTTPS will cause clients to reject the certificate even when everything else is configured correctly.

⚠ Warning: Microsoft Cloud PKI cannot issue the certificate for this. Cloud PKI requires the CSR to be generated via SCEP before signing, and Connected Cache's CSR workflow doesn't go through SCEP at all. Use an internal CA (ADCS or similar) or an external public CA instead.

Step 1: generate the CSR on the Connected Cache node itself

This step can't be skipped or done elsewhere — the private key is generated and kept on the node, and only the node can pair it with the signed certificate later.

Locate the installer scripts, then generate the CSR

Push-Location (deliveryoptimization-cli mcc-get-scripts-path)

# Run generateCsr with your parameters. The Subject and SAN MUST match
# exactly how client devices reach this node - FQDN if they use FQDN,
# IP if they use IP. A mismatch doesn't break CSR generation, but it
# makes clients bypass the cache later because they won't trust the
# certificate.
.\generateCsr.ps1 -Subject "CN=mcc-node-site02.contoso.com" -San "mcc-node-site02.contoso.com"

The command runs inside Connected Cache's managed WSL distribution and writes a timestamped .csr file to the Windows-side Certificates\certs folder, plus a full log to Certificates\logs.

✅ Tip: during a successful run you may see lines like mkdir: cannot create directory '/keys': Permission denied. These are harmless — the script checks for folders before creating them, and an "already exists" check prints as a warning. The run succeeded if you see CSR generation completed successfully and a .csr file in the certs folder.

Step 2: sign the CSR with your own CA

Signing happens entirely outside Connected Cache, using whatever PKI your organisation already trusts — internal ADCS, another enterprise CA, or an external public CA. The only hard requirement on the Connected Cache side: the certificate must come back as an unencrypted .crt file. Password-protected formats, including .pfx, cannot currently be imported, even if they contain the right certificate. Place the signed .crt in the same certs folder as the CSR — the two files don't need matching names.

Step 3: import the signed certificate

Import the signed certificate

# Run from the same scripts directory used for CSR generation
.\importCert.ps1 -CertPath "C:\...\Certificates\certs\mcc-node-site02.crt"

A successful import runs cryptographic verification confirming the certificate, the CSR and the private key all match, copies the certificate into the Connected Cache container, and restarts the container with HTTPS enabled for Intune content endpoints. You generally won't see new files appear in the Windows-side folder after a successful import — the changes happen inside the container, not on disk.

Step 4: configuring a ConfigMgr-integrated node instead

If your Connected Cache node runs on a Configuration Manager distribution point rather than standalone, the process is different — this is not the CSR/import workflow above.

Enable a TLS binding in IIS on the distribution point, using a certificate from your own CA.
Download the updated DOINCInstall.exe installer (the HTTPS-capable build, shipped with the February 2026 Connected Cache update for ConfigMgr).
In the Connected Cache configuration for that distribution point, toggle Connected Cache off, then back on to force it to pick up the new IIS TLS binding.

Proof it worked: confirming the cache is being used again

Two checks, in order: first that HTTPS is actually live on the node, then that clients are actually using it again.

Check one: the node itself

Confirm the import completed by checking the import log's checkpoint sequence — a successful run shows, in order: Certificate file validation passed, then a line matching the certificate to the CSR that generated its private key. If import fails, these logs show exactly which checkpoint didn't complete; SAN or hostname mismatches specifically do not show up at this stage, only later during client-side validation.

Check two: cache hit rate from a real device

Test from an actual managed client, not from the server itself. Trigger a Win32 app install on a pilot device at the site served by this node, and confirm the download completes against the local node's address rather than a CDN endpoint. A sustained rise in bandwidth that drops back down once this fix lands is the clearest real-world confirmation.

✅ Tip: test in a non-production environment before rolling the certificate change out to every node. One misconfigured Subject/SAN value silently pushes every device at that site back to CDN delivery until someone notices — exactly the invisible failure mode this whole post exists to prevent.

Quick reference: requirements, content scope, and log checkpoints

Requirement	Value
Enforcement date	16 June 2026
Minimum cache node software version	2.0.0.2112
Port required free	443
Accepted certificate format	Unencrypted .crt only — no .pfx / .p12
Cloud PKI compatible?	No — requires SCEP-generated CSR, which Connected Cache's workflow doesn't use
ConfigMgr-integrated process	IIS TLS binding + re-run DOINCInstall.exe + toggle Connected Cache off/on
If HTTPS isn't configured	Client falls back to CDN delivery — content still arrives, caching benefit is lost silently

...\Certificates\logs\ (CSR generation and certificate import logs, Connected Cache node)

Log checkpoint (in order)	Meaning
`Algorithm validation passed / CSR name validation passed`	Your CSR inputs were accepted
`Subject Components: ... / SAN Components: ...`	These exact values will be embedded in the CSR — check they match client-facing hostname/IP
`Key verification succeeded`	Private key generated and validated
`CSR verification successful`	OpenSSL validated the CSR structure
`CSR generation completed successfully`	Stage 1 complete
`Certificate file validation passed`	The signed .crt was found and is valid format
`Using CertName: ... / CSR being used: ...`	The certificate was matched to its originating CSR and private key

Glossary

Term	What it means here
Microsoft Connected Cache (MCC)	A free, on-premises content cache that serves repeated large downloads — chiefly Win32 apps and Teams content — locally instead of pulling each copy from Microsoft's cloud over the internet.
CDN fallback	What happens when a client can't use MCC for a piece of content — it downloads directly from Microsoft's Content Delivery Network instead. The install still succeeds; only the local caching benefit is lost.
CSR (Certificate Signing Request)	A file generated on the Connected Cache node itself, containing the public key and identity details, sent to a CA to be signed into a usable certificate.
Subject / SAN	The identity fields embedded in the certificate. Must exactly match the hostname or IP client devices actually use to reach the node, or clients won't trust the certificate.
ConfigMgr-integrated Connected Cache	A Connected Cache deployment running on a Configuration Manager distribution point, configured through IIS rather than the standalone CSR/import scripts.

Frequently asked questions

Will devices fail to get Win32 apps if HTTPS isn't configured?

No. The install still succeeds — the client falls back to downloading from Microsoft's CDN over the internet instead of your local cache node. What's lost is bandwidth savings and provisioning speed, not functionality, which is exactly why this goes unnoticed for so long.

Can I use a Cloud PKI certificate for this?

No. Cloud PKI's certificate issuance requires the CSR to be generated via SCEP before signing, and Connected Cache's CSR workflow does not go through SCEP. Use an internal CA such as ADCS, or a trusted external public CA, instead.

Does this affect Windows Update or Office content served through MCC?

No. Only Intune Win32 apps are newly enforced to HTTPS by this change. Windows feature and quality updates, Microsoft 365 Apps/Click-to-Run, and Defender definition updates continue over HTTP through Connected Cache unaffected. Teams content already required HTTPS before this change and is worth checking at the same time.

Can I reuse a .pfx certificate we already have?

Not directly. Connected Cache can only import unencrypted .crt files at this time — password-protected formats including .pfx and .p12 cannot be imported, even if they contain the correct certificate. Export the certificate from the .pfx in plain .crt format first.

Is the ConfigMgr-integrated process the same as the standalone one?

No, and this is a common point of confusion. A ConfigMgr-integrated Connected Cache node (running on a distribution point) is configured through an IIS TLS binding plus re-running the Connected Cache installer, not the CSR/importCert script workflow used for standalone nodes.

References

How to enable HTTPS support for Microsoft Connected Cache for Enterprise and Education — Intune Customer Success Blog, by Aditya Middha (Product Manager, Microsoft Connected Cache), 20 February 2026. The primary source for the full CSR/sign/import workflow, every prerequisite, and every log checkpoint in this post.
Microsoft Connected Cache — Microsoft Learn, Configuration Manager documentation. Background on Connected Cache deployment generally, including the ConfigMgr-integrated model.
Intune Enforces HTTPS for Win32 Apps, Apple ADE Entra Grouping Goes GA, Android BYOD Moves to AMAPI — Big Hat Group, Kevin Kaminski, 19 June 2026. Corroborates the enforcement date and content-family scope, and is the source for the separate ConfigMgr-integrated (IIS TLS binding) process covered in this post.

Intune Now Requires HTTPS for Win32 Apps: The Connected Cache Fix Nobody Notices They Need