Cloud PKI & Tunnel for MAM | Guided by A Guide to Cloud

Microsoft Cloud PKI

Simple explanation

Think of certificates like digital driver’s licences for your devices.

When a device connects to your Wi-Fi or VPN, it needs to prove who it is. Passwords can be stolen, but a certificate is cryptographically tied to the device — much harder to fake. The problem? Running your own certificate authority (CA) is like running your own driving licence office — expensive, complex, and requires on-prem servers.

Cloud PKI moves the certificate authority to the cloud. Microsoft runs it, Intune distributes the certificates, and you never touch a CA server. Chen Wei at Meridian Bank gets certificate-based Wi-Fi authentication without the infrastructure headache.

Use cases for Cloud PKI

Use Case	How Certificates Help
Wi-Fi authentication (EAP-TLS)	Devices authenticate to corporate Wi-Fi using certificates instead of passwords — no shared Wi-Fi passwords to leak
VPN authentication	Certificate-based VPN eliminates password prompts and resists phishing
S/MIME email	Digitally sign and encrypt emails with user certificates
Mutual TLS	Both client and server verify each other’s identity for sensitive web apps
Device identity	Prove a device is managed and trusted before granting network access

Cloud PKI vs on-premises PKI

Feature	Cloud PKI (Intune Suite)	On-Premises PKI (AD CS)
Infrastructure	None — Microsoft-managed cloud service	Requires Windows Server with AD CS role
Certificate distribution	Intune SCEP/PKCS profiles	NDES server + Intune connector + SCEP profile
Management	Intune admin center	AD CS management console + manual renewal
Maintenance	None — Microsoft handles patching and HA	Regular server patching, backup, monitoring
Best for	Cloud-native orgs or migrating away from on-prem	Existing on-prem infrastructure, complex hierarchies
Licence	Intune Suite add-on	Included with Windows Server

How Cloud PKI issues certificates — the flow

Understanding the issuance flow helps in both the exam and real deployments:

Admin creates a CA in Intune — Intune admin center → Tenant administration → Cloud PKI → Create. You create a root CA first, then an issuing CA signed by that root.
Admin creates a SCEP profile — a device configuration profile that tells devices how to request a certificate (key size, subject name, validity period, intended purpose).
Profile is assigned to a device or user group.
Device receives the profile at next sync and generates a key pair (public + private).
Device sends a Certificate Signing Request (CSR) to Intune containing the public key.
Intune’s Cloud PKI signs the certificate using the issuing CA’s private key.
Signed certificate returns to the device — the device now has a trusted certificate for Wi-Fi, VPN, or other authentication.

Certificate lifecycle

Event	What Happens
Issuance	Device requests → Cloud PKI signs → certificate installed on device
Renewal	Before expiry, Intune automatically triggers a new CSR (if auto-renewal is configured)
Revocation	Admin revokes in Intune → certificate is added to a CRL (Certificate Revocation List) → authentication fails at next check
Expiry	Certificate reaches its validity end date → stops working → device must re-enrol for a new one

Real-world example: Chen Wei at Meridian Bank sets up Cloud PKI with a root CA and issuing CA. He creates a SCEP profile for Wi-Fi (EAP-TLS) targeting all corporate Windows devices. When a new laptop enrolls, it automatically receives a certificate and connects to the “MeridianCorp” Wi-Fi network without any password. When an employee leaves, Chen Wei revokes their device certificate — it can’t connect to Wi-Fi anymore.

Exam tip: root CA vs issuing CA

Cloud PKI uses a two-tier CA hierarchy:

Root CA — the trust anchor. It signs the issuing CA’s certificate. Should be kept offline in on-prem PKI, but Cloud PKI handles this automatically.
Issuing CA — signs end-entity certificates (the ones devices actually use). All SCEP profiles point to the issuing CA.

The exam may ask: “How many CAs does Cloud PKI require?” Answer: two — a root CA and at least one issuing CA. This mirrors the industry best practice of a two-tier PKI hierarchy.

Microsoft Tunnel for MAM

Simple explanation

Imagine a secure tunnel that only specific apps can use — not the whole device.

Regular VPN connects the entire device to your corporate network. That’s fine for corporate laptops, but what about Riko’s designers with personal phones? You don’t want their entire phone traffic going through the company’s network — just Outlook, Teams, and the company intranet.

Tunnel for MAM creates a VPN connection that only managed apps can use. Personal apps bypass the tunnel entirely. It works on devices that aren’t even enrolled in Intune — perfect for BYOD.

Standard Tunnel vs Tunnel for MAM

Feature	Microsoft Tunnel (Standard)	Tunnel for MAM
Device enrollment required	Yes — MDM enrolled	No — works on unenrolled BYOD devices
VPN scope	Device-wide or per-app	Per-app only (managed apps)
Personal traffic	Can route through tunnel	Never routes through tunnel
Supported platforms	iOS, Android, Windows (preview)	iOS, Android
Configuration	Tunnel VPN profile + device config	App protection policy + Tunnel config
Best for	Corporate-managed devices needing VPN	BYOD users accessing internal resources through managed apps

How Tunnel for MAM works

Deploy Microsoft Tunnel Gateway — Linux-based server (or container) in your network
Create an app protection policy — includes Tunnel for MAM settings
User installs managed apps — Outlook, Teams, Edge (with Intune app protection)
User opens a managed app → app connects through the Tunnel → accesses internal resources
Personal apps continue using the regular internet — no corporate tunnel

Key exam concept: Tunnel for MAM is specifically for BYOD scenarios where you want managed apps to access internal resources without enrolling the whole device. If devices are enrolled, use standard Microsoft Tunnel instead.

Exam tip: Tunnel for MAM requirements

The exam may test prerequisites:

Intune Suite licence (add-on)
Microsoft Tunnel Gateway deployed (Linux server or container)
App protection policy configured with Tunnel settings
Microsoft Defender for Endpoint app on the device (acts as the Tunnel client on iOS/Android)
Supported on iOS and Android only (not Windows for MAM Tunnel)

🎬 Video walkthrough

🎬 Video coming soon

Cloud PKI & Tunnel for MAM — MD-102 Module 16

~10 min

Flashcards

Question

What is Microsoft Cloud PKI?

Click or press Enter to reveal answer

Answer

A cloud-based certificate authority in the Intune Suite that issues, renews, and revokes certificates without on-prem PKI infrastructure. Used for Wi-Fi auth (EAP-TLS), VPN, S/MIME email, and device identity. Certificates are distributed via Intune SCEP/PKCS profiles.

Click to flip back

Question

What makes Tunnel for MAM different from standard Microsoft Tunnel?

Click or press Enter to reveal answer

Answer

Tunnel for MAM works on unenrolled BYOD devices and only routes managed app traffic through the VPN. Standard Tunnel requires device enrollment and can route device-wide or per-app traffic. Tunnel for MAM uses app protection policies, not device configuration.

Click to flip back

Question

What acts as the Tunnel client on iOS and Android devices?

Click or press Enter to reveal answer

Answer

Microsoft Defender for Endpoint app — it serves as the Tunnel client for both standard Tunnel and Tunnel for MAM on mobile devices.

Click to flip back

Knowledge Check

Chen Wei needs devices at Meridian Bank to authenticate to corporate Wi-Fi using certificates instead of passwords. The bank has no on-premises certificate servers and doesn't want to build PKI infrastructure. What should Chen Wei use?

Knowledge Check

Riko's designers at Pixel & Co use personal iPhones (not enrolled in Intune) but need to access the company's internal project management site through Outlook and Edge. What's the best approach?

Next up: Remote Actions & Device Queries — managing devices remotely with sync, wipe, retire, and real-time KQL queries.