Two real, dated Microsoft Cloud PKI changes landed within weeks of each other, and neither has a plain-English explainer yet. In-place CA renewal (June 2026) means you no longer have to build a brand-new certificate authority and manually repoint every SCEP profile when your issuing CA approaches expiry — Intune now extends the same CA's life in place, through a safe staged process. GCC High availability (targeted for September 2026) brings Cloud PKI, Remote Help and Enterprise Application Management to Microsoft 365 G5 government tenants at no extra licence cost.
If you manage Cloud PKI at all, the renewal change affects you the moment your first CA hits half its validity lifetime — which, depending on when you set it up, could be right now. This post explains exactly what changes, what to click, and what to check first.
Certificate authority renewal has always been one of those jobs nobody wants on their plate: build a new CA, work out every SCEP profile that pointed at the old one, update each one, and hope nothing breaks in between. Microsoft Cloud PKI just removed almost all of that process for anyone willing to click through a staged rollout instead. This post covers exactly how that works, plus the separate but simultaneous expansion of Cloud PKI (and two other Intune Suite capabilities) into GCC High tenants.
A Cloud PKI issuing CA becomes eligible for renewal at half its validity lifetime. Renewing creates a staged version with its own temporary SCEP URI for testing — up to 50 test certificates, available for 90 days. Once you activate the staged CA, it becomes the new active CA, the old one retires, and — the whole point — your existing SCEP profiles keep working unchanged, because the production SCEP URI never moves. Separately, Microsoft 365 G5 GCC High tenants are gaining Cloud PKI, Remote Help and Enterprise Application Management at no extra cost, targeted for September 2026, alongside Endpoint Privilege Management and Advanced Analytics which are already live. None of this requires the standalone Intune Suite add-on if you already hold G5.
Who needs to read this
| If you are… | What this means for you |
|---|---|
| PKI / certificate admin | Check every Cloud PKI issuing CA's renewal status today — one past the halfway mark needs a plan, and one inside 30 days needs action now. |
| Intune engineer | You no longer need to touch SCEP profiles during a renewal. If your runbook still says "create new CA, update every profile," it's out of date. |
| Government / defense sector admin | If you're on GCC High with Microsoft 365 G5, Cloud PKI, Remote Help and Enterprise Application Management are arriving this month at no extra cost — worth an inventory now, before they land. |
| Security / compliance | Certificate-based Wi-Fi/VPN authentication through a Microsoft-managed CA removes a password from that path entirely — relevant to any Zero Trust or CMMC conversation already underway. |
The problem: renewing a CA used to mean rebuilding everything downstream
Every certificate authority has an expiry date, and an issuing CA nearing the end of its life creates a real operational risk: once it expires, Cloud PKI stops issuing new certificates through it entirely. Existing certificates already issued stay valid until they expire, but nothing new comes out of an expired CA.
The historical fix was blunt. You built a brand-new CA, then went through every SCEP profile that referenced the old one — Wi-Fi, VPN, email, whatever else depended on it — and repointed each to the new CA's SCEP URI. On an estate with more than a handful of profiles, that's a change-control exercise with real risk of missing one, and a certificate-issuance gap for any device that doesn't get the updated profile in time.
Why it happens: how the staged renewal model actually works
In-place renewal exists to remove the rebuild-everything step specifically. The mechanism is a three-stage process, and the detail that makes it work is what happens to the SCEP URI.
Stage 1: Renew — creates a staged CA, doesn't touch production
Selecting Renew on an eligible CA generates a brand-new public/private key pair and a new CA certificate — a renewal always creates fresh cryptographic material, it never reuses the old key pair. This new CA exists as a staged version, with its own temporary SCEP URI, completely separate from the production SCEP URI your real devices are using. Nothing in production changes at this point.
Stage 2: Test — up to 50 certificates, 90 days
The staged CA is there specifically so you can prove it works before committing. Create a test SCEP profile pointed at the temporary URI, assign it to a small pilot group, and confirm certificates actually issue. You get up to 50 test certificates and a 90-day window to do this. If you let the 90 days lapse without activating, the staged CA goes inactive, then is deleted after a further 30-day grace period and its hardware security module resources are reclaimed.
Stage 3: Activate — the production SCEP URI never moves
This is the step that eliminates the old rebuild process. Activating the staged CA promotes it to Active, retires the previous CA version, disables the temporary staged SCEP URI — and restores the original production SCEP URI, now backed by the renewed CA. Every existing SCEP profile keeps pointing at the same URI it always did. You update nothing downstream.
Each renewal also updates the CA's display name with a version suffix, so you can always tell which generation you're looking at:
Bring-your-own-CA (BYOCA) deployments follow the same three stages with one extra step in the middle: renewal generates a certificate signing request (CSR) you download, sign with your own on-premises or private CA, and upload back — only then does the staged CA and its test SCEP URI appear.
How to verify: is a CA in your tenant already overdue?
Everything here is a read-only look at status — nothing changes until you deliberately select Renew.
- Sign in to the Microsoft Intune admin center.
- Go to Tenant administration › Cloud PKI.
- Look at the Renewal column against every certificate authority in the list. This is the one column that tells you whether action is needed right now.
Open any CA to check the detail behind that status: the Properties tab shows current status, active version, validity period and expiration date; the Monitor tab shows active, expired and revoked certificate counts for that CA; the Versions tab lists every staged and prior version with Activate/Revoke actions.
For GCC High tenants, the equivalent check is licensing rather than CA status:
- Confirm whether your tenant holds Microsoft 365 G3 or G5 — Cloud PKI, Remote Help's full scope and Enterprise Application Management are G5-only.
- Open the Intune admin center and look for whether Tenant administration › Cloud PKI is present and provisioned yet — availability is phased by workload and tenant, so a G5 licence doesn't guarantee same-day provisioning.
- Check Message Center for the specific rollout notice for your tenant.
The fix: renewing a CA, and checking your GCC High entitlement
Renewing an Intune-managed CA
- In the Microsoft Intune admin center, go to Tenant administration › Cloud PKI.
- Select the certificate authority you want to renew.
- If it's eligible, select Renew on the command bar. Renew is disabled while the CA's renewal status is already Staged.
- Review the details in the Renew Certification Authority pane, then select Renew to confirm. A staged CA and its temporary SCEP URI are created, and the CA's renewal status changes to Staged.
- Create a SCEP profile that uses the staged SCEP URI, assign it to a small pilot group, and confirm certificates issue successfully. You have up to 90 days and 50 test certificates for this.
- Once satisfied, go to the Versions tab on the CA, select the version with Staged status, and select Activate.
- Remove the test SCEP profile — it was only ever needed for validation against the temporary URI, which is now disabled anyway.
Renewing a bring-your-own-CA (BYOCA) deployment
- Follow steps 1–3 above. BYOCA's Renew is disabled when the status is Signing required or Staged.
- Review the Renew Certification Authority pane and select Renew. This generates a certificate signing request (CSR) — select Download CSR.
- Sign the CSR using the same on-premises or private CA that issued the original certificate.
- Back in the admin center, select Upload signed certificate, browse to the signed
.cer,.crtor.pemfile, and upload it. - After successful validation, the staged CA and its test SCEP URI appear. Continue with testing and activation exactly as for an Intune-managed CA above.
Checking and preparing for GCC High capabilities
- Sign in to the Microsoft Intune admin center for your GCC High tenant and look at what's already provisioned — Intune Plan 2 and Advanced Analytics (G3 and G5) and Endpoint Privilege Management (G5) are available today.
- Check Message Center for the tenant-specific rollout notice covering Remote Help, Enterprise Application Management and Cloud PKI, targeted for September 2026.
- If you're preparing for Cloud PKI specifically, inventory your current certificate templates, which resources consume them, and which fall within Intune's supported certificate scenarios — Microsoft's own guidance is to treat this as consolidation of your device certificate estate, not a wholesale on-premises PKI replacement. Servers, network infrastructure, application signing, offline roots and third-party devices generally stay on existing on-premises PKI.
Proof it worked: what a completed renewal looks like
Two checks confirm a renewal genuinely completed without disruption.
Check one: the CA list shows the new version, active
Check two: existing devices keep getting certificates with no profile change
Pick a device already enrolled with the old SCEP profile, trigger a certificate renewal cycle on it, and confirm it receives a new certificate issued by the renewed CA — without you having touched that device's SCEP profile at all.
Quick reference: every status, banner and timeline
| Renewal banner | Trigger point | What it means |
|---|---|---|
| Halfway to expiration | 50% of validity lifetime elapsed | Informational — review your renewal plan |
| 6 months remaining | 6 months before expiry | Renew now to keep SCEP, Wi-Fi, VPN and email issuance continuous |
| 90 days | 90 days before expiry | Same as above, more urgent |
| 30 days | 30 days before expiry | Without renewal, new issuance could fail; existing certificates stay valid until they expire |
| Expired | Past the validity period | No new certificates issue; renew or create a new CA to restore issuance |
| CA status | Meaning |
|---|---|
| Active | Currently issuing certificates |
| Staged | Renewed version available for testing, not yet promoted |
| Retired | Replaced by an activated renewal |
| Expired | Reached the end of its validity period |
| Revoked | Explicitly revoked by an admin |
| Decommissioned | A staged CA that was never activated and exceeded its lifetime |
| Paused | Still valid, but paused by an admin |
| Signing required | BYOCA only — waiting on a signed CSR upload |
| Item | Value |
|---|---|
| Renewal eligibility | Half of validity lifetime elapsed, or already expired |
| Staged CA test window | 90 days |
| Staged CA grace period after 90 days | 30 additional days, then deleted |
| Test certificates allowed on a staged CA | Up to 50 |
| Required permissions | Read CAs, Create certificate authorities (CAs) |
| CA types supported | Intune-managed issuing CAs, Bring Your Own CA (BYOCA) |
| Production SCEP URI during renewal | Unchanged — only restored/confirmed on activation |
| GCC High capability | G3 | G5 / status |
|---|---|---|
| Intune Plan 2 | Yes | Yes — available today |
| Advanced Analytics | Yes | Yes — available today |
| Endpoint Privilege Management | No | Yes — available today |
| Remote Help | Yes | Yes — targeted September 2026 |
| Enterprise Application Management | No | Yes — targeted September 2026 |
| Microsoft Cloud PKI | No | Yes — targeted September 2026 |
Glossary
| Term | What it means here |
|---|---|
| Cloud PKI | Microsoft's managed certificate authority service for Intune-enrolled devices, removing the need for on-premises CA and NDES infrastructure for supported scenarios. |
| Issuing CA | The certificate authority that actually signs and issues device certificates, as distinct from a root CA. |
| BYOCA | Bring Your Own CA — a Cloud PKI deployment where the issuing certificate is signed by your own existing on-premises or private CA, rather than one Microsoft manages end-to-end. |
| Staged CA | A renewed CA that exists but is not yet active, with its own temporary SCEP URI used purely for pre-activation testing. |
| SCEP URI | The endpoint a SCEP certificate profile points devices to in order to request a certificate. The production URI is what makes in-place renewal transparent to existing profiles. |
| GCC High | Microsoft's Government Community Cloud High environment, serving US federal and defense industrial base customers with additional compliance controls. |
Frequently asked questions
Do I need to update my SCEP profiles after a renewal?
No. The entire point of in-place renewal is that the production SCEP URI is restored unchanged when you activate the staged CA. Existing SCEP profiles keep working without modification.
What happens if I never click Renew?
The CA follows its documented banner sequence — halfway, 6 months, 90 days, 30 days — then expires. An expired CA stops issuing new certificates; devices with certificates already issued keep them until those individually expire. You can still renew an expired CA, but issuance stays unavailable until you activate the resulting staged CA.
Can I test a renewal without any risk to production?
Yes — that's exactly what the staged phase is for. The staged CA uses a separate, temporary SCEP URI, so a test profile pointed at it cannot affect any device using the real production SCEP URI. Nothing in production changes until you explicitly activate.
Does Cloud PKI replace our on-premises PKI entirely?
Not necessarily, and Microsoft's own GCC High guidance is explicit about this: treat Cloud PKI as consolidation of your device certificate estate, not a wholesale replacement. Most organisations continue running on-premises PKI for servers, network infrastructure, application signing, offline roots and third-party devices.
Is Cloud PKI available on Microsoft 365 G3 in GCC High?
No. Cloud PKI, along with Remote Help's full GCC High scope and Enterprise Application Management, is G5-only. G3 gets Intune Plan 2 and Advanced Analytics, plus Remote Help, but not Cloud PKI or Enterprise Application Management.
References
- Renew a Certificate Authority in Cloud PKI — Microsoft Learn. The primary source for the staged renewal model: all three stages, the versioning scheme, every status and banner in this post's quick-reference tables, permissions, and the BYOCA-specific CSR flow.
- Microsoft Cloud PKI for Microsoft Intune — Microsoft Learn. The umbrella documentation for Cloud PKI overall.
- Bring your own certificate authority with Cloud PKI — Microsoft Learn. The full BYOCA setup this post's renewal steps build on.
- Advanced Microsoft Intune capabilities are now available for GCC High — Microsoft Public Sector Blog, 14 September 2026. The source for the GCC High rollout table, licensing split between G3 and G5, and the "consolidation not replacement" guidance for Cloud PKI.
Related reading on EndpointWeekly
- Intune Certificate Profiles: SCEP, PKCS, NDES and the Full Architecture — the general certificate-profile architecture this post's renewal mechanics sit on top of.