Aug. 13, 2026
Microsoft Cloud PKI - Simply Explained
Key Takeaways
- Microsoft Cloud PKI simplifies certificate-based authentication by moving the certificate authority infrastructure out of local server rooms and into the Microsoft Cloud.
- Traditional PKI setups require complex components like Active Directory Certificate Services, NDES servers, reverse proxies, and certificate connectors, creating a heavy burden for IT teams.
- Mirko Peters explains how digital certificates provide a secure alternative to shared passwords, allowing devices to prove their identity without exposing underlying secrets.
- Cloud PKI integrates seamlessly with Microsoft Intune and Entra ID to automatically issue, renew, and revoke certificates for managed Windows, macOS, iOS, iPadOS, and Android devices.
- Using SCEP (Simple Certificate Enrollment Protocol), devices generate their private keys locally, keeping sensitive cryptographic secrets protected while streamlining automatic certificate delivery.
- Cloud PKI is an ideal solution for securing Wi-Fi networks, VPN access, and internal applications without needing a universal replacement for every certificate type in your organization.
Microsoft Cloud PKI brings certificate-based authentication into the cloud—but what exactly does that mean, why would you need certificates, and can it really replace traditional on-premises PKI infrastructure?In this episode of Microsoft Knowledge Nuggets, Mirko Peters explains Microsoft Cloud PKI in plain English. We explore certificates, certificate authorities, Intune, SCEP, device authentication, secure Wi-Fi, VPN access, certificate renewal and revocation, and where Cloud PKI fits into a modern Microsoft environment.
WHY CERTIFICATES EXIST
Every time a device connects to a protected service, there is an identity question: should this device be trusted?Digital certificates provide a way to prove identity without repeatedly sharing passwords. A certificate contains identity information and a public key, while the corresponding private key remains protected on the device. This allows a laptop, phone, or user to prove possession of the certificate without exposing the underlying secret.
WHAT PKI ACTUALLY DOES
PKI stands for Public Key Infrastructure. Think of it as the badge office for your digital workplace.PKI creates certificates, delivers them to the appropriate users or devices, renews certificates before they expire, and revokes them when they should no longer be trusted.At the center is the Certificate Authority, or CA. A typical architecture includes a Root CA establishing trust and an Issuing CA handling the day-to-day issuance of certificates.
THE PROBLEM WITH TRADITIONAL PKI
Traditional Microsoft PKI commonly relies on Windows Server and Active Directory Certificate Services.Connecting modern Intune-managed devices to that infrastructure can require additional components such as certificate connectors, NDES servers, reverse proxies, firewall rules, backups, patching, monitoring, and specialist knowledge.For smaller IT teams, a relatively simple requirement such as certificate-based Wi-Fi can therefore become a substantial infrastructure project.
WHAT MICROSOFT CLOUD PKI IS
Microsoft Cloud PKI is Microsoft's managed Certificate Authority service inside Intune.Instead of operating the certificate infrastructure on local Windows Servers, organizations can use Microsoft-hosted Root and Issuing Certificate Authorities. Cloud PKI can issue certificates to Intune-managed users and devices, renew them, and revoke certificates that should no longer be trusted.ㅤ
INTUNE, ENTRA ID AND CLOUD PKI
The different Microsoft services each have a specific role.Microsoft Entra ID manages identity. Intune manages company devices, applications, configurations, and policies. Cloud PKI provides the certificate infrastructure that can issue trusted digital credentials to those managed devices.Together, they create a model where devices can receive certificates automatically without employees manually requesting or installing them.
HOW SCEP FITS INTO CLOUD PKI
SCEP stands for Simple Certificate Enrollment Protocol.It provides the request path through which a managed device can obtain a certificate. The device generates its private key locally and keeps it there. Cloud PKI receives the public information required to issue the certificate rather than receiving the device's private key.This allows certificate enrollment to happen automatically while keeping the device's most sensitive cryptographic secret protected.
WHAT HAPPENS WHEN A DEVICE NEEDS A CERTIFICAT
EIntune first provides the device with the certificates necessary to trust the organization's certificate chain.The device generates its private key locally and sends a certificate request through SCEP. Intune verifies that the request originates from an enrolled and managed device. When the checks succeed, the Issuing CA signs the certificate and it is delivered back to the device.For the employee, the entire process can happen invisibly in the background.
PASSWORDLESS WI-FI AND VPN ACCESS
Secure Wi-Fi is one of the clearest Cloud PKI use cases.Instead of giving every employee the same Wi-Fi password, each managed device can receive its own certificate. When connecting, the laptop presents the certificate and the network verifies whether it chains back to a trusted Certificate Authority.The same model can be used with compatible VPN services and internal applications that need to recognize managed company devices.ㅤ
CERTIFICATE RENEWAL AND REVOCATION
Certificates intentionally have expiration dates.Cloud PKI and Intune can begin renewing certificates before they expire, allowing devices to obtain replacement certificates in the background.If a laptop is lost, an employee leaves, or a certificate should otherwise stop being trusted, administrators can revoke it. Services checking certificate status can then reject that certificate even if the physical device still exists.
WHERE CLOUD PKI FITS BEST
Cloud PKI is particularly useful when managed company devices need to prove their identity before receiving access.Typical scenarios include certificate-based Wi-Fi, VPN access, and internal applications that should only accept managed devices.The model supports Intune-managed Windows, macOS, iOS, iPadOS, and Android devices where the relevant Intune certificate profiles are supported.ㅤ
WHAT CLOUD PKI DOES NOT REPLACE
Cloud PKI is not a universal replacement for every certificate requirement.Its focus is certificates for Intune-managed devices. It is not intended to replace every certificate used by web servers, VPN gateways, load balancers, unmanaged computers, isolated systems, or unsupported devices.The Wi-Fi controller, VPN gateway, or application also needs to trust the Root and Issuing CA chain used by Cloud PKI.
START WITH ONE USE CASE
Rather than beginning with a company-wide PKI transformation, choose one concrete problem.That could be eliminating a shared Wi-Fi password, improving certificate-based VPN access, or restricting an internal application to managed company laptops.Start with a small pilot group. Configure the trust chain, certificate profile, and corresponding Wi-Fi, VPN, or application policy together. Test enrollment, authentication, renewal, and certificate revocation before expanding deployment.
THE KNOWLEDGE NUGGET
Microsoft Cloud PKI is Microsoft's managed certificate service for Intune-managed devices.It does not replace every PKI workload, but it can significantly simplify certificate-based authentication for Wi-Fi, VPN, and application access by moving much of the traditional certificate infrastructure into Microsoft's cloud.The practical starting point is simple: identify one place where your organization still relies on a shared password for device access, then determine whether Intune and Cloud PKI can replace that shared secret with managed device certificates.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
Frequently Asked Questions
What is Microsoft Cloud PKI?
Microsoft Cloud PKI is Microsoft's managed certificate authority service hosted within Intune. It allows organizations to issue, renew, and revoke digital certificates for managed devices in the cloud without operating traditional on-premises server infrastructure.
How does Microsoft Cloud PKI replace traditional Wi-Fi passwords?
Instead of sharing a single Wi-Fi password across the entire company, Cloud PKI automatically provisions unique digital certificates to Intune-managed devices. When a device connects to the network, it presents its certificate to securely verify its identity.
What is the role of SCEP in Cloud PKI?
SCEP (Simple Certificate Enrollment Protocol) provides a secure communication path for managed devices to request and obtain certificates. The device generates its private key locally and keeps it secure while submitting the public information needed for certificate issuance.
Does Microsoft Cloud PKI replace all types of certificates?
No, Cloud PKI is specifically focused on certificates for Intune-managed devices such as laptops and mobile phones. It is not designed to replace certificates used for public web servers, unmanaged computers, or unsupported network gateways.
1
00:00:00,000 --> 00:00:02,520
Imagine you buy a new laptop for someone joining your business.
2
00:00:02,520 --> 00:00:05,240
They need email, they need shared files, they need the office Wi-Fi,
3
00:00:05,240 --> 00:00:07,200
and maybe a VPN when they work from home.
4
00:00:07,200 --> 00:00:09,280
Each connection asks the same quiet question,
5
00:00:09,280 --> 00:00:11,240
does this laptop belong here?
6
00:00:11,240 --> 00:00:13,760
In many small businesses, the answer is still a password,
7
00:00:13,760 --> 00:00:16,480
a shared Wi-Fi code, a VPN login sent in a message,
8
00:00:16,480 --> 00:00:18,520
then a manual fix when someone changes a password
9
00:00:18,520 --> 00:00:20,520
replaces a laptop or leaves the company,
10
00:00:20,520 --> 00:00:23,080
that might feel like a small office problem, it isn't.
11
00:00:23,080 --> 00:00:25,200
The same question exists in a 10 person company
12
00:00:25,200 --> 00:00:27,000
and a 10,000 person company.
13
00:00:27,000 --> 00:00:28,680
You need a way for a device to prove it belongs
14
00:00:28,680 --> 00:00:31,640
without asking the person using it to keep entering secrets.
15
00:00:31,640 --> 00:00:34,680
I'm Marco Peters from M365, FM and this knowledge nugget
16
00:00:34,680 --> 00:00:37,320
explains certificates, Microsoft Cloud PKI,
17
00:00:37,320 --> 00:00:39,760
and how Intune can handle that proof behind the scenes.
18
00:00:39,760 --> 00:00:42,960
A tiny digital file can replace a password at the office door.
19
00:00:42,960 --> 00:00:45,320
First, let's see why that file exists.
20
00:00:45,320 --> 00:00:46,760
Why certificates exist?
21
00:00:46,760 --> 00:00:48,640
Open a secure website in your browser.
22
00:00:48,640 --> 00:00:50,240
Before you read the page, your browser
23
00:00:50,240 --> 00:00:53,240
checks something in the background, it checks a digital certificate.
24
00:00:53,240 --> 00:00:56,720
That certificate helps the browser confirm it reached the real website
25
00:00:56,720 --> 00:00:58,400
and can create a protected connection.
26
00:00:58,400 --> 00:01:01,520
Most people never see that check, but you rely on it every day.
27
00:01:01,520 --> 00:01:03,960
A certificate works a bit like a company ID badge.
28
00:01:03,960 --> 00:01:06,800
The badge carries a name and details about who it belongs to.
29
00:01:06,800 --> 00:01:09,600
It also carries proof from a badge maker that you trust.
30
00:01:09,600 --> 00:01:12,680
A digital certificate carries a name or identity and a public key.
31
00:01:12,680 --> 00:01:15,280
Think of the public key as information that others can inspect.
32
00:01:15,280 --> 00:01:18,400
The certificate also contains a trusted digital signature,
33
00:01:18,400 --> 00:01:21,320
which says, this badge office checked this identity
34
00:01:21,320 --> 00:01:23,000
and approved this badge.
35
00:01:23,000 --> 00:01:24,880
That gives the guard something to check.
36
00:01:24,880 --> 00:01:26,320
But a badge alone isn't enough.
37
00:01:26,320 --> 00:01:29,120
Someone could pick up a printed badge from a desk.
38
00:01:29,120 --> 00:01:32,160
Digital certificates solve that problem with a private key.
39
00:01:32,160 --> 00:01:33,720
The private key is the holder's secret.
40
00:01:33,720 --> 00:01:36,320
It stays with a laptop, phone, or user.
41
00:01:36,320 --> 00:01:38,680
The device uses it to prove it really owns the certificate,
42
00:01:38,680 --> 00:01:41,160
but it doesn't hand that secret to the Wi-Fi network VPN
43
00:01:41,160 --> 00:01:42,200
or app checking the badge.
44
00:01:42,200 --> 00:01:45,440
Think of it like a guard asking you to unlock your own badge holder
45
00:01:45,440 --> 00:01:47,520
rather than asking you to reveal the combination.
46
00:01:47,520 --> 00:01:50,480
You prove you can open it, but the guard never learns the combination.
47
00:01:50,480 --> 00:01:53,360
That is why certificates can be safer than a shared password.
48
00:01:53,360 --> 00:01:55,040
A shared Wi-Fi password can travel.
49
00:01:55,040 --> 00:01:56,480
Someone can write it down forward it,
50
00:01:56,480 --> 00:01:59,600
reuse it on a personal device, or keep it after leaving the company.
51
00:01:59,600 --> 00:02:02,080
A device certificate gives each managed laptop
52
00:02:02,080 --> 00:02:03,840
or phone its own proof instead.
53
00:02:03,840 --> 00:02:06,560
So who creates and manages these digital badges?
54
00:02:06,560 --> 00:02:09,720
That job belongs to PKI, short for public key infrastructure.
55
00:02:09,720 --> 00:02:11,520
The name sounds heavy, but the idea is simple.
56
00:02:11,520 --> 00:02:14,200
PKI is the badge office for your digital workplace.
57
00:02:14,200 --> 00:02:16,480
It creates certificates, sends them to the right people
58
00:02:16,480 --> 00:02:18,760
or devices, renews them before they expire,
59
00:02:18,760 --> 00:02:21,360
and cancels them when they should no longer work.
60
00:02:21,360 --> 00:02:24,000
Inside that badge office sits a certificate authority,
61
00:02:24,000 --> 00:02:25,560
usually shortened to CA.
62
00:02:25,560 --> 00:02:27,280
A CA is the trusted badge maker.
63
00:02:27,280 --> 00:02:31,280
When a Wi-Fi network, VPN service, or internal app sees a certificate,
64
00:02:31,280 --> 00:02:34,960
it asks one question, do I trust the badge maker that approved this?
65
00:02:34,960 --> 00:02:37,280
If the answer is yes, it can check the certificate
66
00:02:37,280 --> 00:02:39,320
and decide whether to let the device through.
67
00:02:39,320 --> 00:02:42,040
There are usually two layers at the top sits the root CA.
68
00:02:42,040 --> 00:02:45,040
Think of that as company headquarters approving the whole badge system.
69
00:02:45,040 --> 00:02:47,200
It doesn't need to print every badge for every laptop.
70
00:02:47,200 --> 00:02:49,120
Below it sits an issuing CA.
71
00:02:49,120 --> 00:02:50,880
That is the desk that handles the daily work.
72
00:02:50,880 --> 00:02:53,160
It issues certificates for devices and users
73
00:02:53,160 --> 00:02:55,800
while its authority links back to the root CA.
74
00:02:55,800 --> 00:02:57,240
When a service checks the chain,
75
00:02:57,240 --> 00:03:00,080
it can follow the certificate from the laptop to the issuing CA,
76
00:03:00,080 --> 00:03:02,000
then back to the root CA it trusts.
77
00:03:02,000 --> 00:03:04,040
That chain gives the process structure.
78
00:03:04,040 --> 00:03:05,960
You can use this for secure Wi-Fi,
79
00:03:05,960 --> 00:03:08,920
where a laptop proves itself before joining the network.
80
00:03:08,920 --> 00:03:10,480
You can use it for a VPN,
81
00:03:10,480 --> 00:03:11,720
where the laptop proves it belongs
82
00:03:11,720 --> 00:03:13,720
before reaching company resources from home.
83
00:03:13,720 --> 00:03:15,440
You can also use it for an internal app
84
00:03:15,440 --> 00:03:18,120
that should only accept managed company devices.
85
00:03:18,120 --> 00:03:20,280
The employee doesn't need to understand any of that.
86
00:03:20,280 --> 00:03:23,240
They open the laptop, choose the company Wi-Fi and connect.
87
00:03:23,240 --> 00:03:24,240
That's the aim.
88
00:03:24,240 --> 00:03:26,600
The difficult part starts when your badge office
89
00:03:26,600 --> 00:03:28,720
lives in a server room.
90
00:03:28,720 --> 00:03:31,520
Why traditional PKI becomes a small business burden?
91
00:03:31,520 --> 00:03:33,600
For many years, this badge system meant building
92
00:03:33,600 --> 00:03:35,120
and running your own equipment.
93
00:03:35,120 --> 00:03:36,280
You'd install Windows Server,
94
00:03:36,280 --> 00:03:38,280
then add Active Directory Certificate Services,
95
00:03:38,280 --> 00:03:39,760
often called ADCS,
96
00:03:39,760 --> 00:03:42,640
which runs the certificate authority inside your company network.
97
00:03:42,640 --> 00:03:45,080
But the server alone isn't the whole story.
98
00:03:45,080 --> 00:03:46,840
If you use Intune Managed Devices,
99
00:03:46,840 --> 00:03:49,960
they need a way to ask that local certificate authority
100
00:03:49,960 --> 00:03:50,960
for a certificate.
101
00:03:50,960 --> 00:03:53,440
That means setting up an Intune Certificate Connector
102
00:03:53,440 --> 00:03:55,960
and NDES server to handle certificate requests,
103
00:03:55,960 --> 00:03:58,440
a reverse proxy for safe access from outside
104
00:03:58,440 --> 00:04:01,120
and firewall rules that allow the right traffic through.
105
00:04:01,120 --> 00:04:02,320
Each piece has a job.
106
00:04:02,320 --> 00:04:04,160
Together, they can turn a simple goal
107
00:04:04,160 --> 00:04:06,880
like password-free Wi-Fi into a full server project.
108
00:04:06,880 --> 00:04:07,800
Here's an analogy.
109
00:04:07,800 --> 00:04:09,520
Imagine you want to print staff access cards
110
00:04:09,520 --> 00:04:10,320
in your own office.
111
00:04:10,320 --> 00:04:11,640
You don't just buy a card printer.
112
00:04:11,640 --> 00:04:13,040
You build a locked room for it.
113
00:04:13,040 --> 00:04:15,360
You add locked cabinets for the card stock and records.
114
00:04:15,360 --> 00:04:16,760
You install backup power.
115
00:04:16,760 --> 00:04:18,360
You set rules for who may enter,
116
00:04:18,360 --> 00:04:19,480
then you need someone who knows
117
00:04:19,480 --> 00:04:22,160
which switch to use when the printer stops working.
118
00:04:22,160 --> 00:04:25,360
That's closer to traditional PKI than most people expect.
119
00:04:25,360 --> 00:04:27,800
A small business may only want laptops to join Wi-Fi
120
00:04:27,800 --> 00:04:30,080
without sharing one password between everyone
121
00:04:30,080 --> 00:04:32,960
or it may want a VPN that recognizes a managed laptop
122
00:04:32,960 --> 00:04:35,360
before it asks the employee to sign in.
123
00:04:35,360 --> 00:04:36,760
Reasonable goals.
124
00:04:36,760 --> 00:04:39,760
Yet the old route can require servers, network rules,
125
00:04:39,760 --> 00:04:41,120
public access planning,
126
00:04:41,120 --> 00:04:43,840
and knowledge that many small IT teams simply don't have time
127
00:04:43,840 --> 00:04:44,800
to build.
128
00:04:44,800 --> 00:04:46,400
And the work doesn't stop after setup.
129
00:04:46,400 --> 00:04:49,560
Servers need updates. Hardware reaches the end of its life.
130
00:04:49,560 --> 00:04:52,520
Backups need testing, not just a green tick in a backup tool.
131
00:04:52,520 --> 00:04:54,680
Certificates have expired dates and the system needs
132
00:04:54,680 --> 00:04:57,160
to renew them before those dates arrive.
133
00:04:57,160 --> 00:04:59,960
When renewal fails, the first sign may come from an employee
134
00:04:59,960 --> 00:05:02,520
who can't join Wi-Fi on a busy Monday morning.
135
00:05:02,520 --> 00:05:05,240
The employee's password might still work perfectly.
136
00:05:05,240 --> 00:05:07,040
Their laptop can still open word and email
137
00:05:07,040 --> 00:05:08,360
from a mobile connection,
138
00:05:08,360 --> 00:05:10,400
but the certificate that lets the network recognize
139
00:05:10,400 --> 00:05:11,920
that laptop may have expired.
140
00:05:11,920 --> 00:05:13,280
The VPN can refuse it.
141
00:05:13,280 --> 00:05:14,640
An internal app can refuse it.
142
00:05:14,640 --> 00:05:15,880
Wi-Fi can refuse it.
143
00:05:15,880 --> 00:05:18,920
That turns into a support call that sounds strange at first.
144
00:05:18,920 --> 00:05:21,280
My password works, but I can't get online.
145
00:05:21,280 --> 00:05:23,280
Then somebody needs to find out whether the problem
146
00:05:23,280 --> 00:05:25,320
sits in the device, the certificate profile,
147
00:05:25,320 --> 00:05:27,640
the network service, the local CA, the connector,
148
00:05:27,640 --> 00:05:28,800
or the firewall.
149
00:05:28,800 --> 00:05:32,000
A small IT team can lose half a day following that trail.
150
00:05:32,000 --> 00:05:33,720
Remote work adds another layer.
151
00:05:33,720 --> 00:05:35,360
A laptop sitting in the office can reach
152
00:05:35,360 --> 00:05:37,480
the local certificate services more easily,
153
00:05:37,480 --> 00:05:39,080
but a laptop at someone's kitchen table
154
00:05:39,080 --> 00:05:41,960
still needs a safe route to collect a certificate or a new one.
155
00:05:41,960 --> 00:05:43,880
You can expose part of the process carefully
156
00:05:43,880 --> 00:05:46,320
through a reverse proxy and firewall rules.
157
00:05:46,320 --> 00:05:48,360
That works when it's planned and maintained properly,
158
00:05:48,360 --> 00:05:50,840
but it also adds more moving parts, more settings,
159
00:05:50,840 --> 00:05:53,640
and more places for a small error to interrupt access.
160
00:05:53,640 --> 00:05:55,320
The cost isn't only a server license,
161
00:05:55,320 --> 00:05:57,760
it's time spent patching, it's specialist knowledge,
162
00:05:57,760 --> 00:05:59,960
it's documentation that must stay current.
163
00:05:59,960 --> 00:06:01,800
It's the risk that one person understands
164
00:06:01,800 --> 00:06:04,200
the certificate system, then leaves the company
165
00:06:04,200 --> 00:06:05,640
with the map in their head.
166
00:06:05,640 --> 00:06:08,120
PKI itself isn't reserved for large companies.
167
00:06:08,120 --> 00:06:10,440
A small business can benefit from the same kind
168
00:06:10,440 --> 00:06:12,320
of device proof as a large company.
169
00:06:12,320 --> 00:06:14,440
The problem is that running old-style PKI
170
00:06:14,440 --> 00:06:17,400
can demand the effort of a much larger IT department.
171
00:06:17,400 --> 00:06:20,040
Microsoft Cloud PKI keeps the certificate process,
172
00:06:20,040 --> 00:06:22,440
but shifts much of that machinery out of your server room
173
00:06:22,440 --> 00:06:24,240
and into the Microsoft Cloud.
174
00:06:24,240 --> 00:06:26,440
What Microsoft Cloud PKI actually is.
175
00:06:26,440 --> 00:06:28,320
Microsoft Cloud PKI is Microsoft's
176
00:06:28,320 --> 00:06:31,040
managed certificate authority service inside Intune.
177
00:06:31,040 --> 00:06:32,440
That's the plain English definition.
178
00:06:32,440 --> 00:06:34,680
It creates and manages certificates for devices
179
00:06:34,680 --> 00:06:36,200
and uses that Intune manages.
180
00:06:36,200 --> 00:06:38,080
Instead of your company running the badge system
181
00:06:38,080 --> 00:06:40,120
on local servers, Microsoft runs
182
00:06:40,120 --> 00:06:42,400
the certificate authority service in the cloud.
183
00:06:42,400 --> 00:06:44,920
Your employees won't open an app called Cloud PKI,
184
00:06:44,920 --> 00:06:46,480
click a button to request a certificate,
185
00:06:46,480 --> 00:06:48,720
save a file, or remember another password.
186
00:06:48,720 --> 00:06:50,680
Cloud PKI works behind the scenes.
187
00:06:50,680 --> 00:06:53,120
It can issue a certificate when a managed device needs one,
188
00:06:53,120 --> 00:06:55,400
renew it before it expires, and revoke it
189
00:06:55,400 --> 00:06:57,320
when that certificate should no longer work.
190
00:06:57,320 --> 00:06:59,440
Let's use the Office Building analogy again.
191
00:06:59,440 --> 00:07:00,920
Enter ID sits at reception.
192
00:07:00,920 --> 00:07:03,920
It knows who people are and controls their sign-in identity.
193
00:07:03,920 --> 00:07:05,880
Intune acts like the building manager.
194
00:07:05,880 --> 00:07:08,560
It knows which laptops and phones belong to the company
195
00:07:08,560 --> 00:07:10,960
and it sends their settings, apps, and rules.
196
00:07:10,960 --> 00:07:14,120
Cloud PKI is the secure badge office inside that building.
197
00:07:14,120 --> 00:07:15,520
Intune tells the badge office
198
00:07:15,520 --> 00:07:17,360
which manage devices need access.
199
00:07:17,360 --> 00:07:19,240
Cloud PKI creates the certificate.
200
00:07:19,240 --> 00:07:20,840
Then the device can use that certificate
201
00:07:20,840 --> 00:07:22,880
when it connects to services your company has set up
202
00:07:22,880 --> 00:07:23,720
to trust it.
203
00:07:23,720 --> 00:07:25,080
Each service has a clear role.
204
00:07:25,080 --> 00:07:26,640
You don't need a local Windows server
205
00:07:26,640 --> 00:07:28,600
running a root certificate authority.
206
00:07:28,600 --> 00:07:30,280
You don't need another local server acting
207
00:07:30,280 --> 00:07:31,880
as an issuing certificate authority.
208
00:07:31,880 --> 00:07:34,440
Microsoft can host both parts in a cloud first setup
209
00:07:34,440 --> 00:07:35,600
with a root CA at the top
210
00:07:35,600 --> 00:07:37,440
and an issuing CA handling the certificates
211
00:07:37,440 --> 00:07:38,680
used by your devices.
212
00:07:38,680 --> 00:07:40,680
That removes a lot of equipment from the plan.
213
00:07:40,680 --> 00:07:43,840
It also changes who handles the underlying certificate service.
214
00:07:43,840 --> 00:07:45,200
In licensed production use,
215
00:07:45,200 --> 00:07:47,920
Microsoft protects the certificate authority keys
216
00:07:47,920 --> 00:07:51,080
with hardware security modules, usually called HSMs.
217
00:07:51,080 --> 00:07:53,200
And HSM is locked vault hardware
218
00:07:53,200 --> 00:07:55,720
built to protect highly sensitive cryptographic keys.
219
00:07:55,720 --> 00:07:57,840
You don't need to buy, rack, patch, or guard
220
00:07:57,840 --> 00:07:59,040
that hardware yourself.
221
00:07:59,040 --> 00:08:00,840
Microsoft runs it as part of the service.
222
00:08:00,840 --> 00:08:03,200
Your job stays focused on the business decision
223
00:08:03,200 --> 00:08:05,280
which devices should receive certificates
224
00:08:05,280 --> 00:08:07,640
and what should those certificates let them access?
225
00:08:07,640 --> 00:08:09,400
There's one short name worth knowing here.
226
00:08:09,400 --> 00:08:10,480
Ski P.
227
00:08:10,480 --> 00:08:12,880
It means simple certificate enrollment protocol.
228
00:08:12,880 --> 00:08:15,480
You don't need to remember the full name after this episode.
229
00:08:15,480 --> 00:08:17,480
Think of SkiP as the protected request lane
230
00:08:17,480 --> 00:08:20,160
between a managed device and the badge office.
231
00:08:20,160 --> 00:08:22,560
A laptop uses that lane to request a certificate.
232
00:08:22,560 --> 00:08:25,000
Cloud PKI checks the request through Intune
233
00:08:25,000 --> 00:08:26,640
and returns the sign certificate
234
00:08:26,640 --> 00:08:28,680
when the request passes those checks.
235
00:08:28,680 --> 00:08:31,120
The device doesn't send its private secret across that lane.
236
00:08:31,120 --> 00:08:32,200
That detail matters.
237
00:08:32,200 --> 00:08:34,040
The device creates its private key locally
238
00:08:34,040 --> 00:08:35,000
then keeps it there.
239
00:08:35,000 --> 00:08:37,280
Cloud PKI receives a request containing
240
00:08:37,280 --> 00:08:39,480
the public information it needs to issue the certificate
241
00:08:39,480 --> 00:08:41,000
not the device's private key.
242
00:08:41,000 --> 00:08:43,760
Cloud PKI supports the device family's most small businesses
243
00:08:43,760 --> 00:08:44,760
already use.
244
00:08:44,760 --> 00:08:47,600
That includes Windows laptops, Macs, iPhones, iPads,
245
00:08:47,600 --> 00:08:48,920
and Android devices.
246
00:08:48,920 --> 00:08:50,320
The condition is simple.
247
00:08:50,320 --> 00:08:53,040
The device must be enrolled and managed through Intune
248
00:08:53,040 --> 00:08:56,360
and its platform must support Intune's certificate profile.
249
00:08:56,360 --> 00:08:58,600
A personal laptop that isn't managed through Intune
250
00:08:58,600 --> 00:08:59,960
doesn't fit this model.
251
00:08:59,960 --> 00:09:01,440
That boundary is deliberate.
252
00:09:01,440 --> 00:09:03,640
Cloud PKI uses Intune's knowledge of the device
253
00:09:03,640 --> 00:09:04,840
as part of the process.
254
00:09:04,840 --> 00:09:07,240
So it works best where your company controls the setup
255
00:09:07,240 --> 00:09:09,600
and can apply its security rules.
256
00:09:09,600 --> 00:09:11,360
Before planning around it, check licensing.
257
00:09:11,360 --> 00:09:13,680
Cloud PKI requires the right Microsoft licensing
258
00:09:13,680 --> 00:09:17,160
alongside Intune, Microsoft changes plan details over time.
259
00:09:17,160 --> 00:09:18,640
So check your current entitlement
260
00:09:18,640 --> 00:09:20,680
and confirm who needs a license before you design
261
00:09:20,680 --> 00:09:21,920
the service around it.
262
00:09:21,920 --> 00:09:24,080
The certificate authority may now live in the cloud,
263
00:09:24,080 --> 00:09:27,280
but the certificate still has to reach the right laptop safely.
264
00:09:27,280 --> 00:09:30,520
That journey explains why Cloud PKI works so well for modern work.
265
00:09:30,520 --> 00:09:32,560
So imagine a new employee opens their Intune
266
00:09:32,560 --> 00:09:35,960
and manage laptop for the first time, and needs to join secure Wi-Fi
267
00:09:35,960 --> 00:09:38,320
or user VPN.
268
00:09:38,320 --> 00:09:40,800
What happens when a device needs a certificate?
269
00:09:40,800 --> 00:09:42,480
Imagine a new employee sitting down
270
00:09:42,480 --> 00:09:44,880
with their company laptop on the first morning at home.
271
00:09:44,880 --> 00:09:46,760
That laptop is already enrolled in Intune.
272
00:09:46,760 --> 00:09:48,440
They'll need the office Wi-Fi when they get there
273
00:09:48,440 --> 00:09:51,120
and probably a VPN to reach internal systems from home.
274
00:09:51,120 --> 00:09:53,240
But they shouldn't have to hunt for a Wi-Fi password
275
00:09:53,240 --> 00:09:55,200
or call IT for a certificate.
276
00:09:55,200 --> 00:09:58,040
Before the laptop even asks for its own certificate,
277
00:09:58,040 --> 00:10:00,840
Intune sends over the certificates it needs to trust.
278
00:10:00,840 --> 00:10:03,360
That includes the root certificate and the issuing certificate
279
00:10:03,360 --> 00:10:04,680
from your Cloud PKI setup.
280
00:10:04,680 --> 00:10:06,240
Sounds like a small detail, right?
281
00:10:06,240 --> 00:10:07,640
Actually, it's the whole foundation.
282
00:10:07,640 --> 00:10:11,400
It tells the laptop, this is the certificate authority you can trust.
283
00:10:11,400 --> 00:10:13,800
It, without that trust, the laptop has no way to know
284
00:10:13,800 --> 00:10:16,440
whether a certificate came from your company's approved service
285
00:10:16,440 --> 00:10:17,720
or some random place.
286
00:10:17,720 --> 00:10:20,280
Next, the laptop generates its own private key.
287
00:10:20,280 --> 00:10:21,840
This happens right on the device itself
288
00:10:21,840 --> 00:10:23,640
and that private key never leaves.
289
00:10:23,640 --> 00:10:25,400
It doesn't get copied into Intune,
290
00:10:25,400 --> 00:10:28,280
sent to Cloud PKI or passed along to the Wi-Fi service.
291
00:10:28,280 --> 00:10:30,560
That separation is what keeps the secret safe.
292
00:10:30,560 --> 00:10:32,520
Then the laptop prepares a certificate request.
293
00:10:32,520 --> 00:10:34,680
This request includes the public information needed
294
00:10:34,680 --> 00:10:37,400
for the certificate plus proof that the laptop controls
295
00:10:37,400 --> 00:10:38,840
its own private key.
296
00:10:38,840 --> 00:10:40,680
It sends that request through SHEP,
297
00:10:40,680 --> 00:10:42,920
the protected request path we talked about earlier.
298
00:10:42,920 --> 00:10:44,640
Only the request travels, not the key.
299
00:10:44,640 --> 00:10:46,480
Now, Intune plays an active role in the check.
300
00:10:46,480 --> 00:10:48,200
It confirms the request comes from a device
301
00:10:48,200 --> 00:10:50,280
that's enrolled and managed by your company.
302
00:10:50,280 --> 00:10:52,800
It also protects the request so the Cloud PKI service
303
00:10:52,800 --> 00:10:55,480
can verify it hasn't been tampered with along the way.
304
00:10:55,480 --> 00:10:58,160
If the request doesn't match what Intune expects,
305
00:10:58,160 --> 00:10:59,640
no certificate gets issued.
306
00:10:59,640 --> 00:11:01,880
That stops an unknown laptop from just asking for one
307
00:11:01,880 --> 00:11:02,920
and getting it.
308
00:11:02,920 --> 00:11:05,360
When all checks pass, Cloud PKI sends the request
309
00:11:05,360 --> 00:11:07,200
to the issuing certificate authority.
310
00:11:07,200 --> 00:11:10,680
The issuing CA signs a certificate for that device identity
311
00:11:10,680 --> 00:11:12,800
and Intune delivers it back to the laptop.
312
00:11:12,800 --> 00:11:14,240
The employee doesn't see any of this.
313
00:11:14,240 --> 00:11:15,560
They just open the laptop.
314
00:11:15,560 --> 00:11:17,120
And when they arrive at the office,
315
00:11:17,120 --> 00:11:19,280
the Wi-Fi network can ask the laptop for proof.
316
00:11:19,280 --> 00:11:20,960
Instead of typing a shared password,
317
00:11:20,960 --> 00:11:22,840
the laptop presents its certificate.
318
00:11:22,840 --> 00:11:24,920
The network then checks the certificate chain.
319
00:11:24,920 --> 00:11:27,960
Was this certificate issued by the issuing CA at trusts
320
00:11:27,960 --> 00:11:30,840
and does that issuing CA link back to the root CA at trusts?
321
00:11:30,840 --> 00:11:33,120
If those checks pass, the laptop connects.
322
00:11:33,120 --> 00:11:34,880
The same pattern works with a VPN.
323
00:11:34,880 --> 00:11:37,360
A VPN service can check whether the device certificate
324
00:11:37,360 --> 00:11:39,200
belongs to a managed company laptop
325
00:11:39,200 --> 00:11:40,840
before allowing a connection.
326
00:11:40,840 --> 00:11:42,400
An internal app can do the same.
327
00:11:42,400 --> 00:11:44,760
Only accepting devices that carry a certificate
328
00:11:44,760 --> 00:11:46,560
from your approved certificate authority.
329
00:11:46,560 --> 00:11:48,560
The certificate doesn't replace every sign and prompt
330
00:11:48,560 --> 00:11:51,200
everywhere, but it gives the service another strong way
331
00:11:51,200 --> 00:11:52,440
to identify the device.
332
00:11:52,440 --> 00:11:54,560
Now let's talk about the part people usually only notice
333
00:11:54,560 --> 00:11:55,480
when it breaks.
334
00:11:55,480 --> 00:11:56,720
Expirey.
335
00:11:56,720 --> 00:11:59,280
Certificates don't last forever, and that's deliberate.
336
00:11:59,280 --> 00:12:00,560
A certificate needs an end date,
337
00:12:00,560 --> 00:12:02,880
so an old device credential can't keep working forever
338
00:12:02,880 --> 00:12:03,960
without another check.
339
00:12:03,960 --> 00:12:05,880
CloudPKi and Intune can start renewal
340
00:12:05,880 --> 00:12:08,800
before that date arrives whenever the managed device checks in.
341
00:12:08,800 --> 00:12:11,080
The laptop requests a replacement certificate,
342
00:12:11,080 --> 00:12:13,760
and the whole process follows the same protected path.
343
00:12:13,760 --> 00:12:15,440
For the employee, nothing changes.
344
00:12:15,440 --> 00:12:16,360
They connect to Wi-Fi.
345
00:12:16,360 --> 00:12:17,720
They use the VPN.
346
00:12:17,720 --> 00:12:19,720
The certificate renews in the background,
347
00:12:19,720 --> 00:12:21,960
instead of becoming a surprise support ticket
348
00:12:21,960 --> 00:12:23,280
on the day it expires.
349
00:12:23,280 --> 00:12:25,680
A lost laptop needs a different response.
350
00:12:25,680 --> 00:12:27,920
If a device disappears and employee leaves,
351
00:12:27,920 --> 00:12:30,720
or you suspect the certificate shouldn't be trusted anymore,
352
00:12:30,720 --> 00:12:33,600
an administrator can revoke that certificate in Intune.
353
00:12:33,600 --> 00:12:36,800
CloudPKi publishes that change, so services that check
354
00:12:36,800 --> 00:12:39,320
certificate status can reject the old certificate.
355
00:12:39,320 --> 00:12:41,120
The device may still physically exist,
356
00:12:41,120 --> 00:12:42,800
but its digital proof stops working.
357
00:12:42,800 --> 00:12:45,360
That's a much better position than changing a shared Wi-Fi
358
00:12:45,360 --> 00:12:47,520
password and hoping every former employee,
359
00:12:47,520 --> 00:12:50,400
old laptop and personal phone no longer has it.
360
00:12:50,400 --> 00:12:52,000
Still, automatic certificate delivery
361
00:12:52,000 --> 00:12:54,760
doesn't mean CloudPKi handles every certificate task
362
00:12:54,760 --> 00:12:55,680
in your business.
363
00:12:55,680 --> 00:12:57,840
It works very well for a specific set of jobs.
364
00:12:57,840 --> 00:13:00,520
Other jobs need a different certificate service.
365
00:13:00,520 --> 00:13:02,320
And knowing that boundary will save you time
366
00:13:02,320 --> 00:13:03,920
before you start building.
367
00:13:03,920 --> 00:13:06,000
Where CloudPKi fits and where it doesn't,
368
00:13:06,000 --> 00:13:08,520
CloudPKi fits best when you need a managed company device
369
00:13:08,520 --> 00:13:10,480
to prove itself before it gets access.
370
00:13:10,480 --> 00:13:12,000
Secure Wi-Fi is a classic example.
371
00:13:12,000 --> 00:13:15,000
Instead of telling every new starter the same wireless password,
372
00:13:15,000 --> 00:13:18,040
Intune can place a certificate on their managed laptop or phone,
373
00:13:18,040 --> 00:13:20,120
and the network can accept that certificate.
374
00:13:20,120 --> 00:13:22,080
VPN access is another strong fit.
375
00:13:22,080 --> 00:13:24,840
A managed laptop can present its certificate when it connects,
376
00:13:24,840 --> 00:13:26,520
removing repeated password prompts,
377
00:13:26,520 --> 00:13:29,000
and giving the VPN another way to verify the device
378
00:13:29,000 --> 00:13:30,360
before allowing access.
379
00:13:30,360 --> 00:13:32,120
Some internal apps can use the same approach
380
00:13:32,120 --> 00:13:35,040
when they need to accept only devices your company manages.
381
00:13:35,040 --> 00:13:38,400
This works across managed Windows laptops, Macs, iPhones,
382
00:13:38,400 --> 00:13:40,040
iPads and Android devices.
383
00:13:40,040 --> 00:13:43,120
For a small business, that changes a familiar problem.
384
00:13:43,120 --> 00:13:45,720
A shared Wi-Fi password tends to spread.
385
00:13:45,720 --> 00:13:48,600
It appears in welcome emails, chat messages, notebooks,
386
00:13:48,600 --> 00:13:49,720
and old phones.
387
00:13:49,720 --> 00:13:51,480
When someone leaves, changing it can mean
388
00:13:51,480 --> 00:13:55,320
reconnecting every printer, laptop, tablet, and meeting room device.
389
00:13:55,320 --> 00:13:57,360
With device certificates, each managed device
390
00:13:57,360 --> 00:13:59,240
carries its own access proof.
391
00:13:59,240 --> 00:14:01,320
The access decision also becomes more precise.
392
00:14:01,320 --> 00:14:04,080
A password only proves that someone knows the password.
393
00:14:04,080 --> 00:14:06,360
A certificate issued through CloudPKi
394
00:14:06,360 --> 00:14:09,520
connects access to a device that Intune knows and manages.
395
00:14:09,520 --> 00:14:11,720
That supports the idea behind zero trust.
396
00:14:11,720 --> 00:14:13,480
Don't grant access just because something
397
00:14:13,480 --> 00:14:14,920
sits on the office network.
398
00:14:14,920 --> 00:14:17,920
Check the device and its proof each time the service asks.
399
00:14:17,920 --> 00:14:19,600
There are two common ways to start.
400
00:14:19,600 --> 00:14:21,360
If your business runs mostly in the cloud
401
00:14:21,360 --> 00:14:23,480
and has no existing certificate system,
402
00:14:23,480 --> 00:14:26,760
you can create a root CA and issuing CA in CloudPKi.
403
00:14:26,760 --> 00:14:29,320
Then you configure your managed devices, Wi-Fi servers,
404
00:14:29,320 --> 00:14:32,400
VPN gateway, or selected apps to trust that certificate chain.
405
00:14:32,400 --> 00:14:33,640
That's the clean start path.
406
00:14:33,640 --> 00:14:35,760
If you already run a certificate authority,
407
00:14:35,760 --> 00:14:37,640
you don't always need to throw it away.
408
00:14:37,640 --> 00:14:40,000
CloudPKi can use an issuing CA that links back
409
00:14:40,000 --> 00:14:43,040
to an existing root CA, so your new Intune managed devices
410
00:14:43,040 --> 00:14:45,560
can fit into trust rules you already use.
411
00:14:45,560 --> 00:14:48,720
The right path depends on what your network already trusts.
412
00:14:48,720 --> 00:14:50,600
But CloudPKi has a firm boundary.
413
00:14:50,600 --> 00:14:52,960
It targets devices enrolled in Intune.
414
00:14:52,960 --> 00:14:54,800
It doesn't issue every type of certificate
415
00:14:54,800 --> 00:14:57,160
for every machine or service your business owns.
416
00:14:57,160 --> 00:14:59,000
For example, it isn't a general replacement
417
00:14:59,000 --> 00:15:01,760
for certificates on web servers, VPN gateways,
418
00:15:01,760 --> 00:15:03,440
load balances or other servers.
419
00:15:03,440 --> 00:15:06,720
It also doesn't solve certificate needs for unmanaged computers,
420
00:15:06,720 --> 00:15:08,920
isolated systems with no cloud connection,
421
00:15:08,920 --> 00:15:11,680
or Linux devices outside Intune support.
422
00:15:11,680 --> 00:15:13,200
That doesn't reduce its usefulness.
423
00:15:13,200 --> 00:15:15,640
It simply means you should match the tool to the job.
424
00:15:15,640 --> 00:15:18,880
CloudPKi handles certificates for your managed user devices.
425
00:15:18,880 --> 00:15:20,600
Another service may still handle certificates
426
00:15:20,600 --> 00:15:22,600
for the systems those devices connect to.
427
00:15:22,600 --> 00:15:25,080
Your Wi-Fi controller, VPN gateway, or internal app
428
00:15:25,080 --> 00:15:26,520
also needs setup work.
429
00:15:26,520 --> 00:15:28,640
It must trust the root and issuing certificate chain
430
00:15:28,640 --> 00:15:30,200
that CloudPKi uses.
431
00:15:30,200 --> 00:15:32,800
If that service doesn't recognize your certificate authority,
432
00:15:32,800 --> 00:15:35,120
it will reject a perfectly good device certificate.
433
00:15:35,120 --> 00:15:37,480
The device side and the service side must agree.
434
00:15:37,480 --> 00:15:39,840
One planning point can save frustration later.
435
00:15:39,840 --> 00:15:41,400
When you create a certificate authority,
436
00:15:41,400 --> 00:15:43,400
you choose what its certificates can do.
437
00:15:43,400 --> 00:15:45,680
Those choices need to match your planned use.
438
00:15:45,680 --> 00:15:49,320
Client authentication for Wi-Fi or VPN access, for example.
439
00:15:49,320 --> 00:15:52,160
If you choose too narrowly and later need a different purpose,
440
00:15:52,160 --> 00:15:54,400
you may need to create a new certificate authority
441
00:15:54,400 --> 00:15:55,880
and move devices across.
442
00:15:55,880 --> 00:15:58,360
Decide the first use case before you create anything.
443
00:15:58,360 --> 00:16:00,120
That brings us away from the technical diagram
444
00:16:00,120 --> 00:16:02,120
and back to a simple business choice.
445
00:16:02,120 --> 00:16:03,640
Where would a device certificate remove
446
00:16:03,640 --> 00:16:05,760
a real access problem for your staff?
447
00:16:05,760 --> 00:16:08,160
A sensible starting point for a small business.
448
00:16:08,160 --> 00:16:10,160
So where should a small business start?
449
00:16:10,160 --> 00:16:12,320
Begin with one problem, not a company-wide certificate
450
00:16:12,320 --> 00:16:13,080
rollout.
451
00:16:13,080 --> 00:16:15,960
Maybe your staff Wi-Fi still uses one shared password.
452
00:16:15,960 --> 00:16:18,360
Or your VPN makes people log in again and again.
453
00:16:18,360 --> 00:16:19,480
Perhaps you have an internal app
454
00:16:19,480 --> 00:16:21,560
that should only open for managed company laptops.
455
00:16:21,560 --> 00:16:22,720
Pick one problem.
456
00:16:22,720 --> 00:16:24,720
Then make sure the basics are in place.
457
00:16:24,720 --> 00:16:26,640
Are those devices enrolled in Intune?
458
00:16:26,640 --> 00:16:28,480
Do users sign in through EntraID?
459
00:16:28,480 --> 00:16:31,720
Does your Microsoft licensing include what CloudPKi needs?
460
00:16:31,720 --> 00:16:33,520
Run a small pilot to answer those questions
461
00:16:33,520 --> 00:16:34,920
without affecting everyone?
462
00:16:34,920 --> 00:16:36,680
Select a limited group of devices,
463
00:16:36,680 --> 00:16:38,520
build a trust chain, the certificate profile,
464
00:16:38,520 --> 00:16:40,360
and the matching Wi-Fi or VPN policy
465
00:16:40,360 --> 00:16:42,280
together as one connected task.
466
00:16:42,280 --> 00:16:44,120
Don't treat the certificate as separate
467
00:16:44,120 --> 00:16:46,400
because the network service needs to know which certificate
468
00:16:46,400 --> 00:16:47,240
chain to accept.
469
00:16:47,240 --> 00:16:49,880
Bring in the person who owns that network or app early on.
470
00:16:49,880 --> 00:16:51,840
They may need to add your CloudPKi root
471
00:16:51,840 --> 00:16:53,800
and issuing certificates to their service,
472
00:16:53,800 --> 00:16:56,080
and they need to confirm how it checks certificates.
473
00:16:56,080 --> 00:16:58,040
Test more than the first connection.
474
00:16:58,040 --> 00:16:59,400
Make sure renewal works.
475
00:16:59,400 --> 00:17:01,640
Then test what happens when you revoke a certificate
476
00:17:01,640 --> 00:17:02,800
for a lost device.
477
00:17:02,800 --> 00:17:04,200
After that, staff just connect.
478
00:17:04,200 --> 00:17:06,720
I'd can see the certificate lifecycle from Intune.
479
00:17:06,720 --> 00:17:08,800
And the business avoids building and maintaining
480
00:17:08,800 --> 00:17:11,320
its own certificate printing room.
481
00:17:11,320 --> 00:17:12,800
Here's the knowledge nugget to keep.
482
00:17:12,800 --> 00:17:16,240
Microsoft CloudPKi is Microsoft's managed certificate service
483
00:17:16,240 --> 00:17:17,800
for devices managed by Intune.
484
00:17:17,800 --> 00:17:19,920
It won't replace every PKI task you have,
485
00:17:19,920 --> 00:17:21,280
but it can remove a lot of work
486
00:17:21,280 --> 00:17:24,320
around device-based Wi-Fi, VPN, and app access.
487
00:17:24,320 --> 00:17:25,680
Your challenge is simple.
488
00:17:25,680 --> 00:17:28,360
Write down one place where your business still relies
489
00:17:28,360 --> 00:17:30,200
on a shared password for device access.
490
00:17:30,200 --> 00:17:32,160
Then check if those devices use Intune
491
00:17:32,160 --> 00:17:34,400
if CloudPKi supports the platform,
492
00:17:34,400 --> 00:17:36,560
and if the Wi-Fi service, VPN or app
493
00:17:36,560 --> 00:17:38,440
can trust its certificate chain.
494
00:17:38,440 --> 00:17:40,360
Next, look at Intune, EnterID,
495
00:17:40,360 --> 00:17:43,360
and certificate-based Wi-Fi as connected building blocks.
496
00:17:43,360 --> 00:17:46,880
Subscribe on m365.fm and send this episode to the person
497
00:17:46,880 --> 00:17:50,080
who's still keeping that old certificate server running.
00:00:00,000 --> 00:00:02,520
Imagine you buy a new laptop for someone joining your business.
2
00:00:02,520 --> 00:00:05,240
They need email, they need shared files, they need the office Wi-Fi,
3
00:00:05,240 --> 00:00:07,200
and maybe a VPN when they work from home.
4
00:00:07,200 --> 00:00:09,280
Each connection asks the same quiet question,
5
00:00:09,280 --> 00:00:11,240
does this laptop belong here?
6
00:00:11,240 --> 00:00:13,760
In many small businesses, the answer is still a password,
7
00:00:13,760 --> 00:00:16,480
a shared Wi-Fi code, a VPN login sent in a message,
8
00:00:16,480 --> 00:00:18,520
then a manual fix when someone changes a password
9
00:00:18,520 --> 00:00:20,520
replaces a laptop or leaves the company,
10
00:00:20,520 --> 00:00:23,080
that might feel like a small office problem, it isn't.
11
00:00:23,080 --> 00:00:25,200
The same question exists in a 10 person company
12
00:00:25,200 --> 00:00:27,000
and a 10,000 person company.
13
00:00:27,000 --> 00:00:28,680
You need a way for a device to prove it belongs
14
00:00:28,680 --> 00:00:31,640
without asking the person using it to keep entering secrets.
15
00:00:31,640 --> 00:00:34,680
I'm Marco Peters from M365, FM and this knowledge nugget
16
00:00:34,680 --> 00:00:37,320
explains certificates, Microsoft Cloud PKI,
17
00:00:37,320 --> 00:00:39,760
and how Intune can handle that proof behind the scenes.
18
00:00:39,760 --> 00:00:42,960
A tiny digital file can replace a password at the office door.
19
00:00:42,960 --> 00:00:45,320
First, let's see why that file exists.
20
00:00:45,320 --> 00:00:46,760
Why certificates exist?
21
00:00:46,760 --> 00:00:48,640
Open a secure website in your browser.
22
00:00:48,640 --> 00:00:50,240
Before you read the page, your browser
23
00:00:50,240 --> 00:00:53,240
checks something in the background, it checks a digital certificate.
24
00:00:53,240 --> 00:00:56,720
That certificate helps the browser confirm it reached the real website
25
00:00:56,720 --> 00:00:58,400
and can create a protected connection.
26
00:00:58,400 --> 00:01:01,520
Most people never see that check, but you rely on it every day.
27
00:01:01,520 --> 00:01:03,960
A certificate works a bit like a company ID badge.
28
00:01:03,960 --> 00:01:06,800
The badge carries a name and details about who it belongs to.
29
00:01:06,800 --> 00:01:09,600
It also carries proof from a badge maker that you trust.
30
00:01:09,600 --> 00:01:12,680
A digital certificate carries a name or identity and a public key.
31
00:01:12,680 --> 00:01:15,280
Think of the public key as information that others can inspect.
32
00:01:15,280 --> 00:01:18,400
The certificate also contains a trusted digital signature,
33
00:01:18,400 --> 00:01:21,320
which says, this badge office checked this identity
34
00:01:21,320 --> 00:01:23,000
and approved this badge.
35
00:01:23,000 --> 00:01:24,880
That gives the guard something to check.
36
00:01:24,880 --> 00:01:26,320
But a badge alone isn't enough.
37
00:01:26,320 --> 00:01:29,120
Someone could pick up a printed badge from a desk.
38
00:01:29,120 --> 00:01:32,160
Digital certificates solve that problem with a private key.
39
00:01:32,160 --> 00:01:33,720
The private key is the holder's secret.
40
00:01:33,720 --> 00:01:36,320
It stays with a laptop, phone, or user.
41
00:01:36,320 --> 00:01:38,680
The device uses it to prove it really owns the certificate,
42
00:01:38,680 --> 00:01:41,160
but it doesn't hand that secret to the Wi-Fi network VPN
43
00:01:41,160 --> 00:01:42,200
or app checking the badge.
44
00:01:42,200 --> 00:01:45,440
Think of it like a guard asking you to unlock your own badge holder
45
00:01:45,440 --> 00:01:47,520
rather than asking you to reveal the combination.
46
00:01:47,520 --> 00:01:50,480
You prove you can open it, but the guard never learns the combination.
47
00:01:50,480 --> 00:01:53,360
That is why certificates can be safer than a shared password.
48
00:01:53,360 --> 00:01:55,040
A shared Wi-Fi password can travel.
49
00:01:55,040 --> 00:01:56,480
Someone can write it down forward it,
50
00:01:56,480 --> 00:01:59,600
reuse it on a personal device, or keep it after leaving the company.
51
00:01:59,600 --> 00:02:02,080
A device certificate gives each managed laptop
52
00:02:02,080 --> 00:02:03,840
or phone its own proof instead.
53
00:02:03,840 --> 00:02:06,560
So who creates and manages these digital badges?
54
00:02:06,560 --> 00:02:09,720
That job belongs to PKI, short for public key infrastructure.
55
00:02:09,720 --> 00:02:11,520
The name sounds heavy, but the idea is simple.
56
00:02:11,520 --> 00:02:14,200
PKI is the badge office for your digital workplace.
57
00:02:14,200 --> 00:02:16,480
It creates certificates, sends them to the right people
58
00:02:16,480 --> 00:02:18,760
or devices, renews them before they expire,
59
00:02:18,760 --> 00:02:21,360
and cancels them when they should no longer work.
60
00:02:21,360 --> 00:02:24,000
Inside that badge office sits a certificate authority,
61
00:02:24,000 --> 00:02:25,560
usually shortened to CA.
62
00:02:25,560 --> 00:02:27,280
A CA is the trusted badge maker.
63
00:02:27,280 --> 00:02:31,280
When a Wi-Fi network, VPN service, or internal app sees a certificate,
64
00:02:31,280 --> 00:02:34,960
it asks one question, do I trust the badge maker that approved this?
65
00:02:34,960 --> 00:02:37,280
If the answer is yes, it can check the certificate
66
00:02:37,280 --> 00:02:39,320
and decide whether to let the device through.
67
00:02:39,320 --> 00:02:42,040
There are usually two layers at the top sits the root CA.
68
00:02:42,040 --> 00:02:45,040
Think of that as company headquarters approving the whole badge system.
69
00:02:45,040 --> 00:02:47,200
It doesn't need to print every badge for every laptop.
70
00:02:47,200 --> 00:02:49,120
Below it sits an issuing CA.
71
00:02:49,120 --> 00:02:50,880
That is the desk that handles the daily work.
72
00:02:50,880 --> 00:02:53,160
It issues certificates for devices and users
73
00:02:53,160 --> 00:02:55,800
while its authority links back to the root CA.
74
00:02:55,800 --> 00:02:57,240
When a service checks the chain,
75
00:02:57,240 --> 00:03:00,080
it can follow the certificate from the laptop to the issuing CA,
76
00:03:00,080 --> 00:03:02,000
then back to the root CA it trusts.
77
00:03:02,000 --> 00:03:04,040
That chain gives the process structure.
78
00:03:04,040 --> 00:03:05,960
You can use this for secure Wi-Fi,
79
00:03:05,960 --> 00:03:08,920
where a laptop proves itself before joining the network.
80
00:03:08,920 --> 00:03:10,480
You can use it for a VPN,
81
00:03:10,480 --> 00:03:11,720
where the laptop proves it belongs
82
00:03:11,720 --> 00:03:13,720
before reaching company resources from home.
83
00:03:13,720 --> 00:03:15,440
You can also use it for an internal app
84
00:03:15,440 --> 00:03:18,120
that should only accept managed company devices.
85
00:03:18,120 --> 00:03:20,280
The employee doesn't need to understand any of that.
86
00:03:20,280 --> 00:03:23,240
They open the laptop, choose the company Wi-Fi and connect.
87
00:03:23,240 --> 00:03:24,240
That's the aim.
88
00:03:24,240 --> 00:03:26,600
The difficult part starts when your badge office
89
00:03:26,600 --> 00:03:28,720
lives in a server room.
90
00:03:28,720 --> 00:03:31,520
Why traditional PKI becomes a small business burden?
91
00:03:31,520 --> 00:03:33,600
For many years, this badge system meant building
92
00:03:33,600 --> 00:03:35,120
and running your own equipment.
93
00:03:35,120 --> 00:03:36,280
You'd install Windows Server,
94
00:03:36,280 --> 00:03:38,280
then add Active Directory Certificate Services,
95
00:03:38,280 --> 00:03:39,760
often called ADCS,
96
00:03:39,760 --> 00:03:42,640
which runs the certificate authority inside your company network.
97
00:03:42,640 --> 00:03:45,080
But the server alone isn't the whole story.
98
00:03:45,080 --> 00:03:46,840
If you use Intune Managed Devices,
99
00:03:46,840 --> 00:03:49,960
they need a way to ask that local certificate authority
100
00:03:49,960 --> 00:03:50,960
for a certificate.
101
00:03:50,960 --> 00:03:53,440
That means setting up an Intune Certificate Connector
102
00:03:53,440 --> 00:03:55,960
and NDES server to handle certificate requests,
103
00:03:55,960 --> 00:03:58,440
a reverse proxy for safe access from outside
104
00:03:58,440 --> 00:04:01,120
and firewall rules that allow the right traffic through.
105
00:04:01,120 --> 00:04:02,320
Each piece has a job.
106
00:04:02,320 --> 00:04:04,160
Together, they can turn a simple goal
107
00:04:04,160 --> 00:04:06,880
like password-free Wi-Fi into a full server project.
108
00:04:06,880 --> 00:04:07,800
Here's an analogy.
109
00:04:07,800 --> 00:04:09,520
Imagine you want to print staff access cards
110
00:04:09,520 --> 00:04:10,320
in your own office.
111
00:04:10,320 --> 00:04:11,640
You don't just buy a card printer.
112
00:04:11,640 --> 00:04:13,040
You build a locked room for it.
113
00:04:13,040 --> 00:04:15,360
You add locked cabinets for the card stock and records.
114
00:04:15,360 --> 00:04:16,760
You install backup power.
115
00:04:16,760 --> 00:04:18,360
You set rules for who may enter,
116
00:04:18,360 --> 00:04:19,480
then you need someone who knows
117
00:04:19,480 --> 00:04:22,160
which switch to use when the printer stops working.
118
00:04:22,160 --> 00:04:25,360
That's closer to traditional PKI than most people expect.
119
00:04:25,360 --> 00:04:27,800
A small business may only want laptops to join Wi-Fi
120
00:04:27,800 --> 00:04:30,080
without sharing one password between everyone
121
00:04:30,080 --> 00:04:32,960
or it may want a VPN that recognizes a managed laptop
122
00:04:32,960 --> 00:04:35,360
before it asks the employee to sign in.
123
00:04:35,360 --> 00:04:36,760
Reasonable goals.
124
00:04:36,760 --> 00:04:39,760
Yet the old route can require servers, network rules,
125
00:04:39,760 --> 00:04:41,120
public access planning,
126
00:04:41,120 --> 00:04:43,840
and knowledge that many small IT teams simply don't have time
127
00:04:43,840 --> 00:04:44,800
to build.
128
00:04:44,800 --> 00:04:46,400
And the work doesn't stop after setup.
129
00:04:46,400 --> 00:04:49,560
Servers need updates. Hardware reaches the end of its life.
130
00:04:49,560 --> 00:04:52,520
Backups need testing, not just a green tick in a backup tool.
131
00:04:52,520 --> 00:04:54,680
Certificates have expired dates and the system needs
132
00:04:54,680 --> 00:04:57,160
to renew them before those dates arrive.
133
00:04:57,160 --> 00:04:59,960
When renewal fails, the first sign may come from an employee
134
00:04:59,960 --> 00:05:02,520
who can't join Wi-Fi on a busy Monday morning.
135
00:05:02,520 --> 00:05:05,240
The employee's password might still work perfectly.
136
00:05:05,240 --> 00:05:07,040
Their laptop can still open word and email
137
00:05:07,040 --> 00:05:08,360
from a mobile connection,
138
00:05:08,360 --> 00:05:10,400
but the certificate that lets the network recognize
139
00:05:10,400 --> 00:05:11,920
that laptop may have expired.
140
00:05:11,920 --> 00:05:13,280
The VPN can refuse it.
141
00:05:13,280 --> 00:05:14,640
An internal app can refuse it.
142
00:05:14,640 --> 00:05:15,880
Wi-Fi can refuse it.
143
00:05:15,880 --> 00:05:18,920
That turns into a support call that sounds strange at first.
144
00:05:18,920 --> 00:05:21,280
My password works, but I can't get online.
145
00:05:21,280 --> 00:05:23,280
Then somebody needs to find out whether the problem
146
00:05:23,280 --> 00:05:25,320
sits in the device, the certificate profile,
147
00:05:25,320 --> 00:05:27,640
the network service, the local CA, the connector,
148
00:05:27,640 --> 00:05:28,800
or the firewall.
149
00:05:28,800 --> 00:05:32,000
A small IT team can lose half a day following that trail.
150
00:05:32,000 --> 00:05:33,720
Remote work adds another layer.
151
00:05:33,720 --> 00:05:35,360
A laptop sitting in the office can reach
152
00:05:35,360 --> 00:05:37,480
the local certificate services more easily,
153
00:05:37,480 --> 00:05:39,080
but a laptop at someone's kitchen table
154
00:05:39,080 --> 00:05:41,960
still needs a safe route to collect a certificate or a new one.
155
00:05:41,960 --> 00:05:43,880
You can expose part of the process carefully
156
00:05:43,880 --> 00:05:46,320
through a reverse proxy and firewall rules.
157
00:05:46,320 --> 00:05:48,360
That works when it's planned and maintained properly,
158
00:05:48,360 --> 00:05:50,840
but it also adds more moving parts, more settings,
159
00:05:50,840 --> 00:05:53,640
and more places for a small error to interrupt access.
160
00:05:53,640 --> 00:05:55,320
The cost isn't only a server license,
161
00:05:55,320 --> 00:05:57,760
it's time spent patching, it's specialist knowledge,
162
00:05:57,760 --> 00:05:59,960
it's documentation that must stay current.
163
00:05:59,960 --> 00:06:01,800
It's the risk that one person understands
164
00:06:01,800 --> 00:06:04,200
the certificate system, then leaves the company
165
00:06:04,200 --> 00:06:05,640
with the map in their head.
166
00:06:05,640 --> 00:06:08,120
PKI itself isn't reserved for large companies.
167
00:06:08,120 --> 00:06:10,440
A small business can benefit from the same kind
168
00:06:10,440 --> 00:06:12,320
of device proof as a large company.
169
00:06:12,320 --> 00:06:14,440
The problem is that running old-style PKI
170
00:06:14,440 --> 00:06:17,400
can demand the effort of a much larger IT department.
171
00:06:17,400 --> 00:06:20,040
Microsoft Cloud PKI keeps the certificate process,
172
00:06:20,040 --> 00:06:22,440
but shifts much of that machinery out of your server room
173
00:06:22,440 --> 00:06:24,240
and into the Microsoft Cloud.
174
00:06:24,240 --> 00:06:26,440
What Microsoft Cloud PKI actually is.
175
00:06:26,440 --> 00:06:28,320
Microsoft Cloud PKI is Microsoft's
176
00:06:28,320 --> 00:06:31,040
managed certificate authority service inside Intune.
177
00:06:31,040 --> 00:06:32,440
That's the plain English definition.
178
00:06:32,440 --> 00:06:34,680
It creates and manages certificates for devices
179
00:06:34,680 --> 00:06:36,200
and uses that Intune manages.
180
00:06:36,200 --> 00:06:38,080
Instead of your company running the badge system
181
00:06:38,080 --> 00:06:40,120
on local servers, Microsoft runs
182
00:06:40,120 --> 00:06:42,400
the certificate authority service in the cloud.
183
00:06:42,400 --> 00:06:44,920
Your employees won't open an app called Cloud PKI,
184
00:06:44,920 --> 00:06:46,480
click a button to request a certificate,
185
00:06:46,480 --> 00:06:48,720
save a file, or remember another password.
186
00:06:48,720 --> 00:06:50,680
Cloud PKI works behind the scenes.
187
00:06:50,680 --> 00:06:53,120
It can issue a certificate when a managed device needs one,
188
00:06:53,120 --> 00:06:55,400
renew it before it expires, and revoke it
189
00:06:55,400 --> 00:06:57,320
when that certificate should no longer work.
190
00:06:57,320 --> 00:06:59,440
Let's use the Office Building analogy again.
191
00:06:59,440 --> 00:07:00,920
Enter ID sits at reception.
192
00:07:00,920 --> 00:07:03,920
It knows who people are and controls their sign-in identity.
193
00:07:03,920 --> 00:07:05,880
Intune acts like the building manager.
194
00:07:05,880 --> 00:07:08,560
It knows which laptops and phones belong to the company
195
00:07:08,560 --> 00:07:10,960
and it sends their settings, apps, and rules.
196
00:07:10,960 --> 00:07:14,120
Cloud PKI is the secure badge office inside that building.
197
00:07:14,120 --> 00:07:15,520
Intune tells the badge office
198
00:07:15,520 --> 00:07:17,360
which manage devices need access.
199
00:07:17,360 --> 00:07:19,240
Cloud PKI creates the certificate.
200
00:07:19,240 --> 00:07:20,840
Then the device can use that certificate
201
00:07:20,840 --> 00:07:22,880
when it connects to services your company has set up
202
00:07:22,880 --> 00:07:23,720
to trust it.
203
00:07:23,720 --> 00:07:25,080
Each service has a clear role.
204
00:07:25,080 --> 00:07:26,640
You don't need a local Windows server
205
00:07:26,640 --> 00:07:28,600
running a root certificate authority.
206
00:07:28,600 --> 00:07:30,280
You don't need another local server acting
207
00:07:30,280 --> 00:07:31,880
as an issuing certificate authority.
208
00:07:31,880 --> 00:07:34,440
Microsoft can host both parts in a cloud first setup
209
00:07:34,440 --> 00:07:35,600
with a root CA at the top
210
00:07:35,600 --> 00:07:37,440
and an issuing CA handling the certificates
211
00:07:37,440 --> 00:07:38,680
used by your devices.
212
00:07:38,680 --> 00:07:40,680
That removes a lot of equipment from the plan.
213
00:07:40,680 --> 00:07:43,840
It also changes who handles the underlying certificate service.
214
00:07:43,840 --> 00:07:45,200
In licensed production use,
215
00:07:45,200 --> 00:07:47,920
Microsoft protects the certificate authority keys
216
00:07:47,920 --> 00:07:51,080
with hardware security modules, usually called HSMs.
217
00:07:51,080 --> 00:07:53,200
And HSM is locked vault hardware
218
00:07:53,200 --> 00:07:55,720
built to protect highly sensitive cryptographic keys.
219
00:07:55,720 --> 00:07:57,840
You don't need to buy, rack, patch, or guard
220
00:07:57,840 --> 00:07:59,040
that hardware yourself.
221
00:07:59,040 --> 00:08:00,840
Microsoft runs it as part of the service.
222
00:08:00,840 --> 00:08:03,200
Your job stays focused on the business decision
223
00:08:03,200 --> 00:08:05,280
which devices should receive certificates
224
00:08:05,280 --> 00:08:07,640
and what should those certificates let them access?
225
00:08:07,640 --> 00:08:09,400
There's one short name worth knowing here.
226
00:08:09,400 --> 00:08:10,480
Ski P.
227
00:08:10,480 --> 00:08:12,880
It means simple certificate enrollment protocol.
228
00:08:12,880 --> 00:08:15,480
You don't need to remember the full name after this episode.
229
00:08:15,480 --> 00:08:17,480
Think of SkiP as the protected request lane
230
00:08:17,480 --> 00:08:20,160
between a managed device and the badge office.
231
00:08:20,160 --> 00:08:22,560
A laptop uses that lane to request a certificate.
232
00:08:22,560 --> 00:08:25,000
Cloud PKI checks the request through Intune
233
00:08:25,000 --> 00:08:26,640
and returns the sign certificate
234
00:08:26,640 --> 00:08:28,680
when the request passes those checks.
235
00:08:28,680 --> 00:08:31,120
The device doesn't send its private secret across that lane.
236
00:08:31,120 --> 00:08:32,200
That detail matters.
237
00:08:32,200 --> 00:08:34,040
The device creates its private key locally
238
00:08:34,040 --> 00:08:35,000
then keeps it there.
239
00:08:35,000 --> 00:08:37,280
Cloud PKI receives a request containing
240
00:08:37,280 --> 00:08:39,480
the public information it needs to issue the certificate
241
00:08:39,480 --> 00:08:41,000
not the device's private key.
242
00:08:41,000 --> 00:08:43,760
Cloud PKI supports the device family's most small businesses
243
00:08:43,760 --> 00:08:44,760
already use.
244
00:08:44,760 --> 00:08:47,600
That includes Windows laptops, Macs, iPhones, iPads,
245
00:08:47,600 --> 00:08:48,920
and Android devices.
246
00:08:48,920 --> 00:08:50,320
The condition is simple.
247
00:08:50,320 --> 00:08:53,040
The device must be enrolled and managed through Intune
248
00:08:53,040 --> 00:08:56,360
and its platform must support Intune's certificate profile.
249
00:08:56,360 --> 00:08:58,600
A personal laptop that isn't managed through Intune
250
00:08:58,600 --> 00:08:59,960
doesn't fit this model.
251
00:08:59,960 --> 00:09:01,440
That boundary is deliberate.
252
00:09:01,440 --> 00:09:03,640
Cloud PKI uses Intune's knowledge of the device
253
00:09:03,640 --> 00:09:04,840
as part of the process.
254
00:09:04,840 --> 00:09:07,240
So it works best where your company controls the setup
255
00:09:07,240 --> 00:09:09,600
and can apply its security rules.
256
00:09:09,600 --> 00:09:11,360
Before planning around it, check licensing.
257
00:09:11,360 --> 00:09:13,680
Cloud PKI requires the right Microsoft licensing
258
00:09:13,680 --> 00:09:17,160
alongside Intune, Microsoft changes plan details over time.
259
00:09:17,160 --> 00:09:18,640
So check your current entitlement
260
00:09:18,640 --> 00:09:20,680
and confirm who needs a license before you design
261
00:09:20,680 --> 00:09:21,920
the service around it.
262
00:09:21,920 --> 00:09:24,080
The certificate authority may now live in the cloud,
263
00:09:24,080 --> 00:09:27,280
but the certificate still has to reach the right laptop safely.
264
00:09:27,280 --> 00:09:30,520
That journey explains why Cloud PKI works so well for modern work.
265
00:09:30,520 --> 00:09:32,560
So imagine a new employee opens their Intune
266
00:09:32,560 --> 00:09:35,960
and manage laptop for the first time, and needs to join secure Wi-Fi
267
00:09:35,960 --> 00:09:38,320
or user VPN.
268
00:09:38,320 --> 00:09:40,800
What happens when a device needs a certificate?
269
00:09:40,800 --> 00:09:42,480
Imagine a new employee sitting down
270
00:09:42,480 --> 00:09:44,880
with their company laptop on the first morning at home.
271
00:09:44,880 --> 00:09:46,760
That laptop is already enrolled in Intune.
272
00:09:46,760 --> 00:09:48,440
They'll need the office Wi-Fi when they get there
273
00:09:48,440 --> 00:09:51,120
and probably a VPN to reach internal systems from home.
274
00:09:51,120 --> 00:09:53,240
But they shouldn't have to hunt for a Wi-Fi password
275
00:09:53,240 --> 00:09:55,200
or call IT for a certificate.
276
00:09:55,200 --> 00:09:58,040
Before the laptop even asks for its own certificate,
277
00:09:58,040 --> 00:10:00,840
Intune sends over the certificates it needs to trust.
278
00:10:00,840 --> 00:10:03,360
That includes the root certificate and the issuing certificate
279
00:10:03,360 --> 00:10:04,680
from your Cloud PKI setup.
280
00:10:04,680 --> 00:10:06,240
Sounds like a small detail, right?
281
00:10:06,240 --> 00:10:07,640
Actually, it's the whole foundation.
282
00:10:07,640 --> 00:10:11,400
It tells the laptop, this is the certificate authority you can trust.
283
00:10:11,400 --> 00:10:13,800
It, without that trust, the laptop has no way to know
284
00:10:13,800 --> 00:10:16,440
whether a certificate came from your company's approved service
285
00:10:16,440 --> 00:10:17,720
or some random place.
286
00:10:17,720 --> 00:10:20,280
Next, the laptop generates its own private key.
287
00:10:20,280 --> 00:10:21,840
This happens right on the device itself
288
00:10:21,840 --> 00:10:23,640
and that private key never leaves.
289
00:10:23,640 --> 00:10:25,400
It doesn't get copied into Intune,
290
00:10:25,400 --> 00:10:28,280
sent to Cloud PKI or passed along to the Wi-Fi service.
291
00:10:28,280 --> 00:10:30,560
That separation is what keeps the secret safe.
292
00:10:30,560 --> 00:10:32,520
Then the laptop prepares a certificate request.
293
00:10:32,520 --> 00:10:34,680
This request includes the public information needed
294
00:10:34,680 --> 00:10:37,400
for the certificate plus proof that the laptop controls
295
00:10:37,400 --> 00:10:38,840
its own private key.
296
00:10:38,840 --> 00:10:40,680
It sends that request through SHEP,
297
00:10:40,680 --> 00:10:42,920
the protected request path we talked about earlier.
298
00:10:42,920 --> 00:10:44,640
Only the request travels, not the key.
299
00:10:44,640 --> 00:10:46,480
Now, Intune plays an active role in the check.
300
00:10:46,480 --> 00:10:48,200
It confirms the request comes from a device
301
00:10:48,200 --> 00:10:50,280
that's enrolled and managed by your company.
302
00:10:50,280 --> 00:10:52,800
It also protects the request so the Cloud PKI service
303
00:10:52,800 --> 00:10:55,480
can verify it hasn't been tampered with along the way.
304
00:10:55,480 --> 00:10:58,160
If the request doesn't match what Intune expects,
305
00:10:58,160 --> 00:10:59,640
no certificate gets issued.
306
00:10:59,640 --> 00:11:01,880
That stops an unknown laptop from just asking for one
307
00:11:01,880 --> 00:11:02,920
and getting it.
308
00:11:02,920 --> 00:11:05,360
When all checks pass, Cloud PKI sends the request
309
00:11:05,360 --> 00:11:07,200
to the issuing certificate authority.
310
00:11:07,200 --> 00:11:10,680
The issuing CA signs a certificate for that device identity
311
00:11:10,680 --> 00:11:12,800
and Intune delivers it back to the laptop.
312
00:11:12,800 --> 00:11:14,240
The employee doesn't see any of this.
313
00:11:14,240 --> 00:11:15,560
They just open the laptop.
314
00:11:15,560 --> 00:11:17,120
And when they arrive at the office,
315
00:11:17,120 --> 00:11:19,280
the Wi-Fi network can ask the laptop for proof.
316
00:11:19,280 --> 00:11:20,960
Instead of typing a shared password,
317
00:11:20,960 --> 00:11:22,840
the laptop presents its certificate.
318
00:11:22,840 --> 00:11:24,920
The network then checks the certificate chain.
319
00:11:24,920 --> 00:11:27,960
Was this certificate issued by the issuing CA at trusts
320
00:11:27,960 --> 00:11:30,840
and does that issuing CA link back to the root CA at trusts?
321
00:11:30,840 --> 00:11:33,120
If those checks pass, the laptop connects.
322
00:11:33,120 --> 00:11:34,880
The same pattern works with a VPN.
323
00:11:34,880 --> 00:11:37,360
A VPN service can check whether the device certificate
324
00:11:37,360 --> 00:11:39,200
belongs to a managed company laptop
325
00:11:39,200 --> 00:11:40,840
before allowing a connection.
326
00:11:40,840 --> 00:11:42,400
An internal app can do the same.
327
00:11:42,400 --> 00:11:44,760
Only accepting devices that carry a certificate
328
00:11:44,760 --> 00:11:46,560
from your approved certificate authority.
329
00:11:46,560 --> 00:11:48,560
The certificate doesn't replace every sign and prompt
330
00:11:48,560 --> 00:11:51,200
everywhere, but it gives the service another strong way
331
00:11:51,200 --> 00:11:52,440
to identify the device.
332
00:11:52,440 --> 00:11:54,560
Now let's talk about the part people usually only notice
333
00:11:54,560 --> 00:11:55,480
when it breaks.
334
00:11:55,480 --> 00:11:56,720
Expirey.
335
00:11:56,720 --> 00:11:59,280
Certificates don't last forever, and that's deliberate.
336
00:11:59,280 --> 00:12:00,560
A certificate needs an end date,
337
00:12:00,560 --> 00:12:02,880
so an old device credential can't keep working forever
338
00:12:02,880 --> 00:12:03,960
without another check.
339
00:12:03,960 --> 00:12:05,880
CloudPKi and Intune can start renewal
340
00:12:05,880 --> 00:12:08,800
before that date arrives whenever the managed device checks in.
341
00:12:08,800 --> 00:12:11,080
The laptop requests a replacement certificate,
342
00:12:11,080 --> 00:12:13,760
and the whole process follows the same protected path.
343
00:12:13,760 --> 00:12:15,440
For the employee, nothing changes.
344
00:12:15,440 --> 00:12:16,360
They connect to Wi-Fi.
345
00:12:16,360 --> 00:12:17,720
They use the VPN.
346
00:12:17,720 --> 00:12:19,720
The certificate renews in the background,
347
00:12:19,720 --> 00:12:21,960
instead of becoming a surprise support ticket
348
00:12:21,960 --> 00:12:23,280
on the day it expires.
349
00:12:23,280 --> 00:12:25,680
A lost laptop needs a different response.
350
00:12:25,680 --> 00:12:27,920
If a device disappears and employee leaves,
351
00:12:27,920 --> 00:12:30,720
or you suspect the certificate shouldn't be trusted anymore,
352
00:12:30,720 --> 00:12:33,600
an administrator can revoke that certificate in Intune.
353
00:12:33,600 --> 00:12:36,800
CloudPKi publishes that change, so services that check
354
00:12:36,800 --> 00:12:39,320
certificate status can reject the old certificate.
355
00:12:39,320 --> 00:12:41,120
The device may still physically exist,
356
00:12:41,120 --> 00:12:42,800
but its digital proof stops working.
357
00:12:42,800 --> 00:12:45,360
That's a much better position than changing a shared Wi-Fi
358
00:12:45,360 --> 00:12:47,520
password and hoping every former employee,
359
00:12:47,520 --> 00:12:50,400
old laptop and personal phone no longer has it.
360
00:12:50,400 --> 00:12:52,000
Still, automatic certificate delivery
361
00:12:52,000 --> 00:12:54,760
doesn't mean CloudPKi handles every certificate task
362
00:12:54,760 --> 00:12:55,680
in your business.
363
00:12:55,680 --> 00:12:57,840
It works very well for a specific set of jobs.
364
00:12:57,840 --> 00:13:00,520
Other jobs need a different certificate service.
365
00:13:00,520 --> 00:13:02,320
And knowing that boundary will save you time
366
00:13:02,320 --> 00:13:03,920
before you start building.
367
00:13:03,920 --> 00:13:06,000
Where CloudPKi fits and where it doesn't,
368
00:13:06,000 --> 00:13:08,520
CloudPKi fits best when you need a managed company device
369
00:13:08,520 --> 00:13:10,480
to prove itself before it gets access.
370
00:13:10,480 --> 00:13:12,000
Secure Wi-Fi is a classic example.
371
00:13:12,000 --> 00:13:15,000
Instead of telling every new starter the same wireless password,
372
00:13:15,000 --> 00:13:18,040
Intune can place a certificate on their managed laptop or phone,
373
00:13:18,040 --> 00:13:20,120
and the network can accept that certificate.
374
00:13:20,120 --> 00:13:22,080
VPN access is another strong fit.
375
00:13:22,080 --> 00:13:24,840
A managed laptop can present its certificate when it connects,
376
00:13:24,840 --> 00:13:26,520
removing repeated password prompts,
377
00:13:26,520 --> 00:13:29,000
and giving the VPN another way to verify the device
378
00:13:29,000 --> 00:13:30,360
before allowing access.
379
00:13:30,360 --> 00:13:32,120
Some internal apps can use the same approach
380
00:13:32,120 --> 00:13:35,040
when they need to accept only devices your company manages.
381
00:13:35,040 --> 00:13:38,400
This works across managed Windows laptops, Macs, iPhones,
382
00:13:38,400 --> 00:13:40,040
iPads and Android devices.
383
00:13:40,040 --> 00:13:43,120
For a small business, that changes a familiar problem.
384
00:13:43,120 --> 00:13:45,720
A shared Wi-Fi password tends to spread.
385
00:13:45,720 --> 00:13:48,600
It appears in welcome emails, chat messages, notebooks,
386
00:13:48,600 --> 00:13:49,720
and old phones.
387
00:13:49,720 --> 00:13:51,480
When someone leaves, changing it can mean
388
00:13:51,480 --> 00:13:55,320
reconnecting every printer, laptop, tablet, and meeting room device.
389
00:13:55,320 --> 00:13:57,360
With device certificates, each managed device
390
00:13:57,360 --> 00:13:59,240
carries its own access proof.
391
00:13:59,240 --> 00:14:01,320
The access decision also becomes more precise.
392
00:14:01,320 --> 00:14:04,080
A password only proves that someone knows the password.
393
00:14:04,080 --> 00:14:06,360
A certificate issued through CloudPKi
394
00:14:06,360 --> 00:14:09,520
connects access to a device that Intune knows and manages.
395
00:14:09,520 --> 00:14:11,720
That supports the idea behind zero trust.
396
00:14:11,720 --> 00:14:13,480
Don't grant access just because something
397
00:14:13,480 --> 00:14:14,920
sits on the office network.
398
00:14:14,920 --> 00:14:17,920
Check the device and its proof each time the service asks.
399
00:14:17,920 --> 00:14:19,600
There are two common ways to start.
400
00:14:19,600 --> 00:14:21,360
If your business runs mostly in the cloud
401
00:14:21,360 --> 00:14:23,480
and has no existing certificate system,
402
00:14:23,480 --> 00:14:26,760
you can create a root CA and issuing CA in CloudPKi.
403
00:14:26,760 --> 00:14:29,320
Then you configure your managed devices, Wi-Fi servers,
404
00:14:29,320 --> 00:14:32,400
VPN gateway, or selected apps to trust that certificate chain.
405
00:14:32,400 --> 00:14:33,640
That's the clean start path.
406
00:14:33,640 --> 00:14:35,760
If you already run a certificate authority,
407
00:14:35,760 --> 00:14:37,640
you don't always need to throw it away.
408
00:14:37,640 --> 00:14:40,000
CloudPKi can use an issuing CA that links back
409
00:14:40,000 --> 00:14:43,040
to an existing root CA, so your new Intune managed devices
410
00:14:43,040 --> 00:14:45,560
can fit into trust rules you already use.
411
00:14:45,560 --> 00:14:48,720
The right path depends on what your network already trusts.
412
00:14:48,720 --> 00:14:50,600
But CloudPKi has a firm boundary.
413
00:14:50,600 --> 00:14:52,960
It targets devices enrolled in Intune.
414
00:14:52,960 --> 00:14:54,800
It doesn't issue every type of certificate
415
00:14:54,800 --> 00:14:57,160
for every machine or service your business owns.
416
00:14:57,160 --> 00:14:59,000
For example, it isn't a general replacement
417
00:14:59,000 --> 00:15:01,760
for certificates on web servers, VPN gateways,
418
00:15:01,760 --> 00:15:03,440
load balances or other servers.
419
00:15:03,440 --> 00:15:06,720
It also doesn't solve certificate needs for unmanaged computers,
420
00:15:06,720 --> 00:15:08,920
isolated systems with no cloud connection,
421
00:15:08,920 --> 00:15:11,680
or Linux devices outside Intune support.
422
00:15:11,680 --> 00:15:13,200
That doesn't reduce its usefulness.
423
00:15:13,200 --> 00:15:15,640
It simply means you should match the tool to the job.
424
00:15:15,640 --> 00:15:18,880
CloudPKi handles certificates for your managed user devices.
425
00:15:18,880 --> 00:15:20,600
Another service may still handle certificates
426
00:15:20,600 --> 00:15:22,600
for the systems those devices connect to.
427
00:15:22,600 --> 00:15:25,080
Your Wi-Fi controller, VPN gateway, or internal app
428
00:15:25,080 --> 00:15:26,520
also needs setup work.
429
00:15:26,520 --> 00:15:28,640
It must trust the root and issuing certificate chain
430
00:15:28,640 --> 00:15:30,200
that CloudPKi uses.
431
00:15:30,200 --> 00:15:32,800
If that service doesn't recognize your certificate authority,
432
00:15:32,800 --> 00:15:35,120
it will reject a perfectly good device certificate.
433
00:15:35,120 --> 00:15:37,480
The device side and the service side must agree.
434
00:15:37,480 --> 00:15:39,840
One planning point can save frustration later.
435
00:15:39,840 --> 00:15:41,400
When you create a certificate authority,
436
00:15:41,400 --> 00:15:43,400
you choose what its certificates can do.
437
00:15:43,400 --> 00:15:45,680
Those choices need to match your planned use.
438
00:15:45,680 --> 00:15:49,320
Client authentication for Wi-Fi or VPN access, for example.
439
00:15:49,320 --> 00:15:52,160
If you choose too narrowly and later need a different purpose,
440
00:15:52,160 --> 00:15:54,400
you may need to create a new certificate authority
441
00:15:54,400 --> 00:15:55,880
and move devices across.
442
00:15:55,880 --> 00:15:58,360
Decide the first use case before you create anything.
443
00:15:58,360 --> 00:16:00,120
That brings us away from the technical diagram
444
00:16:00,120 --> 00:16:02,120
and back to a simple business choice.
445
00:16:02,120 --> 00:16:03,640
Where would a device certificate remove
446
00:16:03,640 --> 00:16:05,760
a real access problem for your staff?
447
00:16:05,760 --> 00:16:08,160
A sensible starting point for a small business.
448
00:16:08,160 --> 00:16:10,160
So where should a small business start?
449
00:16:10,160 --> 00:16:12,320
Begin with one problem, not a company-wide certificate
450
00:16:12,320 --> 00:16:13,080
rollout.
451
00:16:13,080 --> 00:16:15,960
Maybe your staff Wi-Fi still uses one shared password.
452
00:16:15,960 --> 00:16:18,360
Or your VPN makes people log in again and again.
453
00:16:18,360 --> 00:16:19,480
Perhaps you have an internal app
454
00:16:19,480 --> 00:16:21,560
that should only open for managed company laptops.
455
00:16:21,560 --> 00:16:22,720
Pick one problem.
456
00:16:22,720 --> 00:16:24,720
Then make sure the basics are in place.
457
00:16:24,720 --> 00:16:26,640
Are those devices enrolled in Intune?
458
00:16:26,640 --> 00:16:28,480
Do users sign in through EntraID?
459
00:16:28,480 --> 00:16:31,720
Does your Microsoft licensing include what CloudPKi needs?
460
00:16:31,720 --> 00:16:33,520
Run a small pilot to answer those questions
461
00:16:33,520 --> 00:16:34,920
without affecting everyone?
462
00:16:34,920 --> 00:16:36,680
Select a limited group of devices,
463
00:16:36,680 --> 00:16:38,520
build a trust chain, the certificate profile,
464
00:16:38,520 --> 00:16:40,360
and the matching Wi-Fi or VPN policy
465
00:16:40,360 --> 00:16:42,280
together as one connected task.
466
00:16:42,280 --> 00:16:44,120
Don't treat the certificate as separate
467
00:16:44,120 --> 00:16:46,400
because the network service needs to know which certificate
468
00:16:46,400 --> 00:16:47,240
chain to accept.
469
00:16:47,240 --> 00:16:49,880
Bring in the person who owns that network or app early on.
470
00:16:49,880 --> 00:16:51,840
They may need to add your CloudPKi root
471
00:16:51,840 --> 00:16:53,800
and issuing certificates to their service,
472
00:16:53,800 --> 00:16:56,080
and they need to confirm how it checks certificates.
473
00:16:56,080 --> 00:16:58,040
Test more than the first connection.
474
00:16:58,040 --> 00:16:59,400
Make sure renewal works.
475
00:16:59,400 --> 00:17:01,640
Then test what happens when you revoke a certificate
476
00:17:01,640 --> 00:17:02,800
for a lost device.
477
00:17:02,800 --> 00:17:04,200
After that, staff just connect.
478
00:17:04,200 --> 00:17:06,720
I'd can see the certificate lifecycle from Intune.
479
00:17:06,720 --> 00:17:08,800
And the business avoids building and maintaining
480
00:17:08,800 --> 00:17:11,320
its own certificate printing room.
481
00:17:11,320 --> 00:17:12,800
Here's the knowledge nugget to keep.
482
00:17:12,800 --> 00:17:16,240
Microsoft CloudPKi is Microsoft's managed certificate service
483
00:17:16,240 --> 00:17:17,800
for devices managed by Intune.
484
00:17:17,800 --> 00:17:19,920
It won't replace every PKI task you have,
485
00:17:19,920 --> 00:17:21,280
but it can remove a lot of work
486
00:17:21,280 --> 00:17:24,320
around device-based Wi-Fi, VPN, and app access.
487
00:17:24,320 --> 00:17:25,680
Your challenge is simple.
488
00:17:25,680 --> 00:17:28,360
Write down one place where your business still relies
489
00:17:28,360 --> 00:17:30,200
on a shared password for device access.
490
00:17:30,200 --> 00:17:32,160
Then check if those devices use Intune
491
00:17:32,160 --> 00:17:34,400
if CloudPKi supports the platform,
492
00:17:34,400 --> 00:17:36,560
and if the Wi-Fi service, VPN or app
493
00:17:36,560 --> 00:17:38,440
can trust its certificate chain.
494
00:17:38,440 --> 00:17:40,360
Next, look at Intune, EnterID,
495
00:17:40,360 --> 00:17:43,360
and certificate-based Wi-Fi as connected building blocks.
496
00:17:43,360 --> 00:17:46,880
Subscribe on m365.fm and send this episode to the person
497
00:17:46,880 --> 00:17:50,080
who's still keeping that old certificate server running.
