Define Cloud PKI certificate purposes before creating the root authority

Source facts

Cloud PKI issuing authorities can select only extended key usages already defined on their root authority. Adding another EKU after creation requires a new CA. A device SCEP profile requesting an EKU absent from its issuing authority fails to obtain a certificate. Microsoft Learn.

Applicability

Use this design check when creating Microsoft Cloud PKI root and issuing authorities. Ask each relying-service owner to identify the certificate purpose required for the planned device-authentication workflow.

DSE recommendation

DSE recommends documenting a purpose matrix across root authority, issuing authority, device profile and relying service before creating the hierarchy. Have the PKI owner approve every required EKU and avoid adding unrelated purposes solely as a precaution. Treat a missing purpose discovered afterward as a hierarchy-design change with its own migration review.

Verification

In an approved pilot, compare the requested and issued certificate purposes with the signed-off matrix and test the intended authentication service. Retain the CA identities and profile settings alongside the result. Resolve an issuance mismatch before assigning the profile broadly or creating replacement authorities.

Official references

Microsoft Learn: Configure root and issuing CA for Microsoft Cloud PKI. Source reviewed September 17, 2026.