Microsoft Cloud PKI - Simply Explained

Imagine you buy a new laptop for someone joining your business. They need email, they need shared files, they need the office Wi-Fi, and maybe a VPN when they work from home. Each connection asks the same quiet question, does this laptop belong here? In many small businesses, the answer is still a password, a shared Wi-Fi code, a VPN login sent in a message, then a manual fix when someone changes a password replaces a laptop or leaves the company, that might feel like a small office problem, it isn't. The same question exists in a 10 person company and a 10,000 person company. You need a way for a device to prove it belongs without asking the person using it to keep entering secrets. I'm Marco Peters from M365, FM and this knowledge nugget explains certificates, Microsoft Cloud PKI, and how Intune can handle that proof behind the scenes. A tiny digital file can replace a password at the office door. First, let's see why that file exists. Why certificates exist? Open a secure website in your browser. Before you read the page, your browser checks something in the background, it checks a digital certificate. That certificate helps the browser confirm it reached the real website and can create a protected connection. Most people never see that check, but you rely on it every day. A certificate works a bit like a company ID badge. The badge carries a name and details about who it belongs to. It also carries proof from a badge maker that you trust. A digital certificate carries a name or identity and a public key. Think of the public key as information that others can inspect. The certificate also contains a trusted digital signature, which says, this badge office checked this identity and approved this badge. That gives the guard something to check. But a badge alone isn't enough. Someone could pick up a printed badge from a desk. Digital certificates solve that problem with a private key. The private key is the holder's secret. It stays with a laptop, phone, or user. The device uses it to prove it really owns the certificate, but it doesn't hand that secret to the Wi-Fi network VPN or app checking the badge. Think of it like a guard asking you to unlock your own badge holder rather than asking you to reveal the combination. You prove you can open it, but the guard never learns the combination. That is why certificates can be safer than a shared password. A shared Wi-Fi password can travel. Someone can write it down forward it, reuse it on a personal device, or keep it after leaving the company. A device certificate gives each managed laptop or phone its own proof instead. So who creates and manages these digital badges? That job belongs to PKI, short for public key infrastructure. The name sounds heavy, but the idea is simple. PKI is the badge office for your digital workplace. It creates certificates, sends them to the right people or devices, renews them before they expire, and cancels them when they should no longer work. Inside that badge office sits a certificate authority, usually shortened to CA. A CA is the trusted badge maker. When a Wi-Fi network, VPN service, or internal app sees a certificate, it asks one question, do I trust the badge maker that approved this? If the answer is yes, it can check the certificate and decide whether to let the device through. There are usually two layers at the top sits the root CA. Think of that as company headquarters approving the whole badge system. It doesn't need to print every badge for every laptop. Below it sits an issuing CA. That is the desk that handles the daily work. It issues certificates for devices and users while its authority links back to the root CA. When a service checks the chain, it can follow the certificate from the laptop to the issuing CA, then back to the root CA it trusts. That chain gives the process structure. You can use this for secure Wi-Fi, where a laptop proves itself before joining the network. You can use it for a VPN, where the laptop proves it belongs before reaching company resources from home. You can also use it for an internal app that should only accept managed company devices. The employee doesn't need to understand any of that. They open the laptop, choose the company Wi-Fi and connect. That's the aim. The difficult part starts when your badge office lives in a server room. Why traditional PKI becomes a small business burden? For many years, this badge system meant building and running your own equipment. You'd install Windows Server, then add Active Directory Certificate Services, often called ADCS, which runs the certificate authority inside your company network. But the server alone isn't the whole story. If you use Intune Managed Devices, they need a way to ask that local certificate authority for a certificate. That means setting up an Intune Certificate Connector and NDES server to handle certificate requests, a reverse proxy for safe access from outside and firewall rules that allow the right traffic through. Each piece has a job. Together, they can turn a simple goal like password-free Wi-Fi into a full server project. Here's an analogy. Imagine you want to print staff access cards in your own office. You don't just buy a card printer. You build a locked room for it. You add locked cabinets for the card stock and records. You install backup power. You set rules for who may enter, then you need someone who knows which switch to use when the printer stops working. That's closer to traditional PKI than most people expect. A small business may only want laptops to join Wi-Fi without sharing one password between everyone or it may want a VPN that recognizes a managed laptop before it asks the employee to sign in. Reasonable goals. Yet the old route can require servers, network rules, public access planning, and knowledge that many small IT teams simply don't have time to build. And the work doesn't stop after setup. Servers need updates. Hardware reaches the end of its life. Backups need testing, not just a green tick in a backup tool. Certificates have expired dates and the system needs to renew them before those dates arrive. When renewal fails, the first sign may come from an employee who can't join Wi-Fi on a busy Monday morning. The employee's password might still work perfectly. Their laptop can still open word and email from a mobile connection, but the certificate that lets the network recognize that laptop may have expired. The VPN can refuse it. An internal app can refuse it. Wi-Fi can refuse it. That turns into a support call that sounds strange at first. My password works, but I can't get online. Then somebody needs to find out whether the problem sits in the device, the certificate profile, the network service, the local CA, the connector, or the firewall. A small IT team can lose half a day following that trail. Remote work adds another layer. A laptop sitting in the office can reach the local certificate services more easily, but a laptop at someone's kitchen table still needs a safe route to collect a certificate or a new one. You can expose part of the process carefully through a reverse proxy and firewall rules. That works when it's planned and maintained properly, but it also adds more moving parts, more settings, and more places for a small error to interrupt access. The cost isn't only a server license, it's time spent patching, it's specialist knowledge, it's documentation that must stay current. It's the risk that one person understands the certificate system, then leaves the company with the map in their head. PKI itself isn't reserved for large companies. A small business can benefit from the same kind of device proof as a large company. The problem is that running old-style PKI can demand the effort of a much larger IT department. Microsoft Cloud PKI keeps the certificate process, but shifts much of that machinery out of your server room and into the Microsoft Cloud. What Microsoft Cloud PKI actually is. Microsoft Cloud PKI is Microsoft's managed certificate authority service inside Intune. That's the plain English definition. It creates and manages certificates for devices and uses that Intune manages. Instead of your company running the badge system on local servers, Microsoft runs the certificate authority service in the cloud. Your employees won't open an app called Cloud PKI, click a button to request a certificate, save a file, or remember another password. Cloud PKI works behind the scenes. It can issue a certificate when a managed device needs one, renew it before it expires, and revoke it when that certificate should no longer work. Let's use the Office Building analogy again. Enter ID sits at reception. It knows who people are and controls their sign-in identity. Intune acts like the building manager. It knows which laptops and phones belong to the company and it sends their settings, apps, and rules. Cloud PKI is the secure badge office inside that building. Intune tells the badge office which manage devices need access. Cloud PKI creates the certificate. Then the device can use that certificate when it connects to services your company has set up to trust it. Each service has a clear role. You don't need a local Windows server running a root certificate authority. You don't need another local server acting as an issuing certificate authority. Microsoft can host both parts in a cloud first setup with a root CA at the top and an issuing CA handling the certificates used by your devices. That removes a lot of equipment from the plan. It also changes who handles the underlying certificate service. In licensed production use, Microsoft protects the certificate authority keys with hardware security modules, usually called HSMs. And HSM is locked vault hardware built to protect highly sensitive cryptographic keys. You don't need to buy, rack, patch, or guard that hardware yourself. Microsoft runs it as part of the service. Your job stays focused on the business decision which devices should receive certificates and what should those certificates let them access? There's one short name worth knowing here. Ski P. It means simple certificate enrollment protocol. You don't need to remember the full name after this episode. Think of SkiP as the protected request lane between a managed device and the badge office. A laptop uses that lane to request a certificate. Cloud PKI checks the request through Intune and returns the sign certificate when the request passes those checks. The device doesn't send its private secret across that lane. That detail matters. The device creates its private key locally then keeps it there. Cloud PKI receives a request containing the public information it needs to issue the certificate not the device's private key. Cloud PKI supports the device family's most small businesses already use. That includes Windows laptops, Macs, iPhones, iPads, and Android devices. The condition is simple. The device must be enrolled and managed through Intune and its platform must support Intune's certificate profile. A personal laptop that isn't managed through Intune doesn't fit this model. That boundary is deliberate. Cloud PKI uses Intune's knowledge of the device as part of the process. So it works best where your company controls the setup and can apply its security rules. Before planning around it, check licensing. Cloud PKI requires the right Microsoft licensing alongside Intune, Microsoft changes plan details over time. So check your current entitlement and confirm who needs a license before you design the service around it. The certificate authority may now live in the cloud, but the certificate still has to reach the right laptop safely. That journey explains why Cloud PKI works so well for modern work. So imagine a new employee opens their Intune and manage laptop for the first time, and needs to join secure Wi-Fi or user VPN. What happens when a device needs a certificate? Imagine a new employee sitting down with their company laptop on the first morning at home. That laptop is already enrolled in Intune. They'll need the office Wi-Fi when they get there and probably a VPN to reach internal systems from home. But they shouldn't have to hunt for a Wi-Fi password or call IT for a certificate. Before the laptop even asks for its own certificate, Intune sends over the certificates it needs to trust. That includes the root certificate and the issuing certificate from your Cloud PKI setup. Sounds like a small detail, right? Actually, it's the whole foundation. It tells the laptop, this is the certificate authority you can trust. It, without that trust, the laptop has no way to know whether a certificate came from your company's approved service or some random place. Next, the laptop generates its own private key. This happens right on the device itself and that private key never leaves. It doesn't get copied into Intune, sent to Cloud PKI or passed along to the Wi-Fi service. That separation is what keeps the secret safe. Then the laptop prepares a certificate request. This request includes the public information needed for the certificate plus proof that the laptop controls its own private key. It sends that request through SHEP, the protected request path we talked about earlier. Only the request travels, not the key. Now, Intune plays an active role in the check. It confirms the request comes from a device that's enrolled and managed by your company. It also protects the request so the Cloud PKI service can verify it hasn't been tampered with along the way. If the request doesn't match what Intune expects, no certificate gets issued. That stops an unknown laptop from just asking for one and getting it. When all checks pass, Cloud PKI sends the request to the issuing certificate authority. The issuing CA signs a certificate for that device identity and Intune delivers it back to the laptop. The employee doesn't see any of this. They just open the laptop. And when they arrive at the office, the Wi-Fi network can ask the laptop for proof. Instead of typing a shared password, the laptop presents its certificate. The network then checks the certificate chain. Was this certificate issued by the issuing CA at trusts and does that issuing CA link back to the root CA at trusts? If those checks pass, the laptop connects. The same pattern works with a VPN. A VPN service can check whether the device certificate belongs to a managed company laptop before allowing a connection. An internal app can do the same. Only accepting devices that carry a certificate from your approved certificate authority. The certificate doesn't replace every sign and prompt everywhere, but it gives the service another strong way to identify the device. Now let's talk about the part people usually only notice when it breaks. Expirey. Certificates don't last forever, and that's deliberate. A certificate needs an end date, so an old device credential can't keep working forever without another check. CloudPKi and Intune can start renewal before that date arrives whenever the managed device checks in. The laptop requests a replacement certificate, and the whole process follows the same protected path. For the employee, nothing changes. They connect to Wi-Fi. They use the VPN. The certificate renews in the background, instead of becoming a surprise support ticket on the day it expires. A lost laptop needs a different response. If a device disappears and employee leaves, or you suspect the certificate shouldn't be trusted anymore, an administrator can revoke that certificate in Intune. CloudPKi publishes that change, so services that check certificate status can reject the old certificate. The device may still physically exist, but its digital proof stops working. That's a much better position than changing a shared Wi-Fi password and hoping every former employee, old laptop and personal phone no longer has it. Still, automatic certificate delivery doesn't mean CloudPKi handles every certificate task in your business. It works very well for a specific set of jobs. Other jobs need a different certificate service. And knowing that boundary will save you time before you start building. Where CloudPKi fits and where it doesn't, CloudPKi fits best when you need a managed company device to prove itself before it gets access. Secure Wi-Fi is a classic example. Instead of telling every new starter the same wireless password, Intune can place a certificate on their managed laptop or phone, and the network can accept that certificate. VPN access is another strong fit. A managed laptop can present its certificate when it connects, removing repeated password prompts, and giving the VPN another way to verify the device before allowing access. Some internal apps can use the same approach when they need to accept only devices your company manages. This works across managed Windows laptops, Macs, iPhones, iPads and Android devices. For a small business, that changes a familiar problem. A shared Wi-Fi password tends to spread. It appears in welcome emails, chat messages, notebooks, and old phones. When someone leaves, changing it can mean reconnecting every printer, laptop, tablet, and meeting room device. With device certificates, each managed device carries its own access proof. The access decision also becomes more precise. A password only proves that someone knows the password. A certificate issued through CloudPKi connects access to a device that Intune knows and manages. That supports the idea behind zero trust. Don't grant access just because something sits on the office network. Check the device and its proof each time the service asks. There are two common ways to start. If your business runs mostly in the cloud and has no existing certificate system, you can create a root CA and issuing CA in CloudPKi. Then you configure your managed devices, Wi-Fi servers, VPN gateway, or selected apps to trust that certificate chain. That's the clean start path. If you already run a certificate authority, you don't always need to throw it away. CloudPKi can use an issuing CA that links back to an existing root CA, so your new Intune managed devices can fit into trust rules you already use. The right path depends on what your network already trusts. But CloudPKi has a firm boundary. It targets devices enrolled in Intune. It doesn't issue every type of certificate for every machine or service your business owns. For example, it isn't a general replacement for certificates on web servers, VPN gateways, load balances or other servers. It also doesn't solve certificate needs for unmanaged computers, isolated systems with no cloud connection, or Linux devices outside Intune support. That doesn't reduce its usefulness. It simply means you should match the tool to the job. CloudPKi handles certificates for your managed user devices. Another service may still handle certificates for the systems those devices connect to. Your Wi-Fi controller, VPN gateway, or internal app also needs setup work. It must trust the root and issuing certificate chain that CloudPKi uses. If that service doesn't recognize your certificate authority, it will reject a perfectly good device certificate. The device side and the service side must agree. One planning point can save frustration later. When you create a certificate authority, you choose what its certificates can do. Those choices need to match your planned use. Client authentication for Wi-Fi or VPN access, for example. If you choose too narrowly and later need a different purpose, you may need to create a new certificate authority and move devices across. Decide the first use case before you create anything. That brings us away from the technical diagram and back to a simple business choice. Where would a device certificate remove a real access problem for your staff? A sensible starting point for a small business. So where should a small business start? Begin with one problem, not a company-wide certificate rollout. Maybe your staff Wi-Fi still uses one shared password. Or your VPN makes people log in again and again. Perhaps you have an internal app that should only open for managed company laptops. Pick one problem. Then make sure the basics are in place. Are those devices enrolled in Intune? Do users sign in through EntraID? Does your Microsoft licensing include what CloudPKi needs? Run a small pilot to answer those questions without affecting everyone? Select a limited group of devices, build a trust chain, the certificate profile, and the matching Wi-Fi or VPN policy together as one connected task. Don't treat the certificate as separate because the network service needs to know which certificate chain to accept. Bring in the person who owns that network or app early on. They may need to add your CloudPKi root and issuing certificates to their service, and they need to confirm how it checks certificates. Test more than the first connection. Make sure renewal works. Then test what happens when you revoke a certificate for a lost device. After that, staff just connect. I'd can see the certificate lifecycle from Intune. And the business avoids building and maintaining its own certificate printing room. Here's the knowledge nugget to keep. Microsoft CloudPKi is Microsoft's managed certificate service for devices managed by Intune. It won't replace every PKI task you have, but it can remove a lot of work around device-based Wi-Fi, VPN, and app access. Your challenge is simple. Write down one place where your business still relies on a shared password for device access. Then check if those devices use Intune if CloudPKi supports the platform, and if the Wi-Fi service, VPN or app can trust its certificate chain. Next, look at Intune, EnterID, and certificate-based Wi-Fi as connected building blocks. Subscribe on m365.fm and send this episode to the person who's still keeping that old certificate server running.