How do you detect a new root certificate authority being added in Microsoft Entra ID?

What is actually changing when a new root CA appears in Entra ID?

A new trusted root is not just another configuration entry. It changes the trust boundary for certificate-based authentication and any policy or workflow that relies on that hierarchy. In practice, the security question is whether the addition was part of an approved certificate lifecycle process or whether it created a new path for trusted authentication that should not exist.

The change matters because root trust is transitive: once a root is trusted, certificates it can issue may be accepted downstream. That makes the addition more sensitive than ordinary tenant configuration drift, especially if certificate-based sign-in, device trust, or hybrid identity workflows depend on the same trust chain.

For a useful baseline, pair the change with the normal certificate lifecycle and CA governance model described in the Machine Identity, PKI and Certificate Lifecycle Guide. The operational question is not simply "did a root appear?" but "did the trust hierarchy change in a way that matches an approved enrollment or CA onboarding process?"

How should you validate whether the root CA addition is expected?

Start by comparing the audit event to the organisation’s normal process for introducing trust anchors. A legitimate change should align with a known request, change window, owner, and purpose, and it should fit the existing certificate authority hierarchy rather than appearing as an isolated or unexplained trust update.

Validation should include who made the change, what object was modified, and whether the new root matches the certificate authority used by the relevant business system or identity workflow. If the certificate chain does not map cleanly to an approved deployment, treat the event as suspicious until proven otherwise.

In Entra-centric environments, the right comparison point is often the broader identity control plane, not just the certificate record itself. The Active Directory and Entra ID Hardening Guide is useful here because trust-anchor changes should be reviewed alongside hybrid identity design, privileged access paths, and certificate services dependencies.

What should you investigate if the root CA is unexpected?

Unexpected root trust additions deserve immediate investigation because they can enable fraudulent authentication if an attacker can issue or present certificates that chain to the trusted root. That turns a single trust change into a potentially broad impersonation path across users, workloads, or applications that accept certificate-based trust.

Look for adjacent signs of compromise in the identity plane: unusual admin activity, new or altered application credentials, consent abuse, federation changes, or other trust modifications that may have happened before or after the root was added. If the root was introduced to support a rogue or unreviewed trust relationship, the safest assumption is that the change may already have been used.

When the event may reflect broader identity compromise, the Identity Threat Detection and Response (ITDR) Guide helps frame the follow-on hunt: confirm whether the change is an isolated administrative action or part of a wider identity attack path.

Risk and Threat Considerations

A newly trusted root CA can expand trust far beyond the original change point. If it is not expected and controlled, it may allow certificate-based impersonation, fraudulent sign-in, or silent persistence inside trust workflows that assume the root is legitimate.

Failure mechanism: An attacker or misconfigured process introduces a root that downstream systems trust, then uses certificates chained to that root to authenticate as an approved entity or to widen access without needing the original secret or password.

Impact: The result can be unauthorized access, difficult-to-detect persistence, and a trust anchor that makes later authentication failures look legitimate unless the hierarchy is actively reviewed.

Practitioner Guidance

What to verify: Confirm the root CA against the approved certificate authority inventory, the change request, and the expected enrollment path. If any of those three do not line up, treat the event as a trust violation rather than a benign configuration update.

Decision rule: If the new root is not clearly tied to a sanctioned CA rollout, isolate the change for immediate review and check whether any certificate-based access paths should be suspended until the trust chain is validated.

Practitioner takeaway: The key judgement is whether the new root changes who can be trusted, not just what was configured, because trust-anchor drift can create authentication risk even when nothing else appears broken.

Related resources from NHI Mgmt Group

• How do you detect a Temporary Access Pass being added to an account in Microsoft Entra ID?
• How do you detect new owners being added to Microsoft Entra applications?
• How do you detect users being added to privileged roles in Microsoft Entra ID?
• What should you monitor to detect suspicious device activity in Microsoft Entra ID?