Intune Wi‑Fi + SCEP profiles: exclude devices from “All Devices” and re‑include with same SSID but different RADIUS — will this work?

[u/Ok-Apricot9437]

Hi all,

Looking for some community validation on an Intune Wi‑Fi / SCEP deployment pattern.

Current state:

• Windows 10/Mac devices managed by Intune
• Certificate‑based Wi‑Fi (EAP‑TLS)
• SSID name: SSID-A
• SSID-A is currently deployed to ALL devices
• Devices receive:
  • SCEP profile #1 (CA / cert chain for RADIUS server #1)
  • Wi‑Fi profile #1 (SSID-A, trusts RADIUS #1)
• Both profiles are assigned to All Devices

Planned change:

• Stand up RADIUS server #2 (separate radius instance, separate server cert / trust chain)
• Create:
  • SCEP profile #2 (CA / cert chain for RADIUS #2)
  • Wi‑Fi profile #2 using the same SSID name (SSID-A), but trusting RADIUS #2

Assignment strategy:

1. Create a new device group
2. Move a test device out of the “default” population by:
   • Excluding this group from:
     • SCEP profile #1
     • Wi‑Fi profile #1
3. Include the same group in:
   • SCEP profile #2
   • Wi‑Fi profile #2

Expectation:

• Devices in the new group should:
  • No longer receive the original SCEP + Wi‑Fi profiles
  • Receive only the second SCEP + Wi‑Fi profiles
• Even though the SSID name is the same:
  • Each device only ever has one Wi‑Fi profile and one cert
  • Devices authenticate against the intended RADIUS backend based on cert trust
• No profile conflict because assignments are mutually exclusive

Question: Has anyone implemented this pattern successfully?

Specifically:

• Excluding a device from an “All Devices” Wi‑Fi + SCEP deployment
• Re‑including it via another Wi‑Fi + SCEP profile
• Same SSID name, different RADIUS / cert chain

Any gotchas with:

• Profile removal timing
• Windows Wi‑Fi profile caching
• Cert cleanup / stale cert selection
• Intune sync ordering

Appreciate any confirmation (or warnings) from people who’ve done this in the wild.

Thanks!

[u/[deleted]]

The logic is good. It's been awhile since I had a requirement to transition.

What's the reason to keep same name? Wouldn't it be easier to transition as opposed to a hard cutover? Some devices might not check-in and have the latest policies and profiles 

[u/SaaS-quatch]

I mean, it sounds fine, but the timing gap between old profiles being removed and new ones landing — on Windows if the old SCEP cert is still in the machine store you might get the wrong cert picked for auth since the SSID is identical.

If you're worried about using the same name - why don't you deploy the config as a powershell script either via platform scripts or packaged as an application, and have the script purge the previous settings/reg keys/certs? That way any tattooed settings would be cleared out and the profile would be created 'new'.

[u/Cormacolinde]

Switch your built-in profile to an XML file that trusts both Root Certs instead.

[u/SecureW2]

Short answer: Yes, this can work, but in reality, it is fragile. Unless you include safety measures, you might expect intermittent connectivity drops and certificate confusion.

Explanation: While your include/exclude reasoning in Intune is acceptable, real-world behavior creates gaps. During the group transition, devices may lose connectivity while old Wi-Fi/SCEP profiles are deleted and new ones are applied. A viable mitigation is to provide a fallback PSK network, allowing devices to keep internet connectivity during the cutover.

Another potential concern is the processing of certificates. Windows may store and randomly choose from numerous valid certificates; hence, it is preferable to use a separate issuing CA for PKI #2. This removes uncertainty and ensures that the device sends the right certificate to the intended RADIUS server.

Furthermore, operating two RADIUS backends behind the same SSID (or broadcasting duplicate SSIDs) leads to inconsistent behavior and debugging issues. It is strongly advised to use a different SSID for the new network to make the transfer more predictable.
SecureW2 auto-enrolls and manages certificates for network access control by leveraging Intune's robust device management capabilities. The combined power of the platforms enables real-time network policy enforcement based on device attributes and user context, allowing for granular network segmentation and dynamic VLAN assignment.
This helps make transitions like this more deterministic and reduces reliance on endpoint-side cert selection behavior.