The owners of the machine should approve changes to the trusted root certificate store, ideally through a formal endpoint or identity governance process. Root trust affects every application on the device, so it is not a local convenience setting. Central security teams should enforce policy, but business or system owners should understand and accept the risk before trust is extended.
Who should approve changes to the trusted root certificate store?
Changes to the trusted root certificate store should be approved by the machine owner, with security and platform teams setting policy and guardrails. Because root trust changes the trust boundary for every application on the endpoint, approval should not be treated as a low-risk local admin action. A formal governance path is the right control point.
Why the approval should sit with the machine owner
The trusted root store is part of the device’s trust foundation. If a new root is added, any certificate chaining to that root can be accepted by the operating system and by software that relies on system trust. That means the impact is broad, persistent, and often invisible to the user after the change is made.
Machine owners are the people best positioned to decide whether that trust extension is justified for the specific endpoint, workload, or business use case. They understand whether the device is corporate-managed, shared, regulated, or tied to a specific application dependency. Security teams can define the rule set, but the owner should accept the business risk of widening the trust boundary.
How approval should work in practice
Approval should be routed through an endpoint governance, identity governance, or change-management workflow rather than ad hoc admin action. The workflow should record what root is being added, why it is needed, which devices are affected, how long it should remain trusted, and who is accountable if the trust decision later proves unsafe.
Where possible, approval should be time-bounded and reviewed periodically. A root certificate that was needed for a migration, inspection proxy, lab environment, or third-party integration should not remain trusted indefinitely without a current justification. The control is stronger when the trust decision is explicit, attributable, and reversible.
What central security should control instead of owning every decision
Central security teams should own the policy, standards, and technical enforcement. They should define which roots are forbidden, which categories require exception handling, and how distribution is performed across the fleet. That prevents inconsistent local decisions and reduces the chance that a single endpoint becomes an unintended trust anchor.
Operationally, the safest model is policy by central teams and approval by the machine owner for exceptions or business-specific trust needs. In managed environments, this can be paired with platform controls that block unsanctioned changes and require a signed request or ticket before the store is updated. For certificate lifecycle context, see the Machine Identity, PKI and Certificate Lifecycle Guide.
When the change affects a non-human trust path, the same ownership principle still applies to the system or workload owner because the trust decision changes authentication and validation behavior across the device or service. The broader machine identity context is covered in Ultimate Guide to NHIs — What are Non-Human Identities, and workload trust architectures are also discussed in Guide to SPIFFE and SPIRE.
Risk and Threat Considerations
A trusted root certificate can silently expand what the endpoint accepts as valid, which makes it attractive for interception, impersonation, and unauthorized inspection. If the wrong root is approved, the device may trust certificates that were never intended for that environment, creating a broad and hard-to-see exposure.
Failure mechanism: A malicious or overly broad root is added to the trusted store, or a legitimate root is approved for the wrong scope, allowing forged or intercepted connections to appear trustworthy to the operating system and applications.
Impact: The device may accept traffic, services, or internal endpoints that should not be trusted, increasing the risk of credential theft, traffic interception, malicious proxying, and persistent trust abuse across many applications.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Root store changes affect endpoint trust assets and need accountable inventory |
| CM-3 — Configuration Change Control | Approving root store updates is a configuration change that alters trust behavior | |
| IA-5 — Authenticator Management | Root trust depends on certificate and key lifecycle decisions | |
| Recommendation — Track trusted root stores as governed components and review changes through approved change control. Require formal change approval for root store modifications before they reach endpoints. Manage certificate and key trust material with approved lifecycle and renewal controls. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Trusted root store updates are security-relevant configuration changes needing control |
| Recommendation — Control and record root certificate store changes through an approved configuration process. | ||
Practitioner Guidance
What to verify: Require a specific business justification, scope, and expiry for every root-store change. If the request cannot name the systems, certificate chain, and removal plan, it is not ready for approval.
Decision rule: If the change broadens trust for all applications on the device, treat it as an exception decision, not a routine endpoint tweak. If the trust need is temporary, prefer a short-lived approval and a scheduled removal date.
What good looks like: Approved roots are centrally visible, tied to an owner, reviewed on a cadence, and removable without breaking undocumented dependencies. The best outcome is not “more roots approved,” but “every approved root has a clear reason and a clear retirement path.”
Practitioner takeaway: The key control is not who can click approve, it is who is accountable for extending trust to the entire device and whether that decision is governed like any other meaningful security exception.
