Keep all calls in an Intune SCEP request on the same NDES server

Source facts

An Intune SCEP request makes three NDES calls: capability discovery, public-key retrieval, and request submission. All three must reach the same actual NDES server. A load balancer that changes the backend during that sequence causes the request to fail, even behind one virtual URL. After failure, the device retries during its next policy cycle. Microsoft Learn.

Applicability

Apply this review to Intune SCEP profiles using multiple NDES endpoints or a virtualized enrollment URL. Inspect backend selection during one enrollment request, not just whether each server responds independently.

DSE recommendation

Have the load-balancer and PKI owners agree on how the full three-call sequence stays with one server. Include planned backend maintenance and failure behavior in that design. Avoid marking the service ready based only on a reachable virtual address or three successful tests that used unrelated enrollment attempts.

Verification

Capture a controlled enrollment’s sanitized routing evidence and correlate its three stages with backend identity. Confirm successful issuance when the intended server remains available, then assess a safely simulated backend disruption against the documented retry behavior. Retain request timing and selected backend without copying challenge material or private keys. Investigate intermittent failures before adding more endpoints or increasing deployment scope.

Official references

Microsoft Learn: Use SCEP certificate profiles with Microsoft Intune.