Managing Trusted Root Certificates on Business Devices: What to Audit, Keep, and Remove

In this article:

• What Trusted Credentials Are and Why Businesses Should Care
• How Certificate Authorities Create SSL Trust on Your Devices
• Default Trust Stores on Windows, Android, and Business Endpoints
• What Trusted Credentials to Disable or Remove
• Rogue Certificate Authorities: The Real Threat to Business Networks
• How to Audit Trusted CAs on Company Devices
• Enforcing Certificate Trust Policy Across Your Fleet
• Close the Certificate Trust Gap

Most business devices arrive with hundreds of pre-loaded certificate authorities baked into their operating system. Your IT team almost certainly has not reviewed that list since initial deployment.

That gap has consequences. Trusted credentials control which encrypted connections your devices accept as legitimate. An unreviewed trust store is an active risk surface that attackers and malicious software can exploit across your entire fleet.

What Trusted Credentials Are and Why Businesses Should Care

Trusted credentials are the pre-loaded list of certificate authorities (CAs) a device recognizes without question when establishing SSL/TLS connections, the encrypted sessions protecting web traffic, application logins, and data transfers. Operating systems ship with this list already populated, covering hundreds of CAs from organizations and governments worldwide.

When your device trusts a CA, it automatically validates every certificate that CA has signed. That includes the certificates used by your business banking portal, internal web applications, and every SaaS platform your team authenticates against throughout the day.

Most organizations deploy devices and never revisit this list. Certificates expire, CAs lose standing with browser vendors, and new authorities get added through software installations, all without anyone in IT tracking the changes.

Certificate trust is foundational endpoint security hygiene. The organizations most likely to miss problems here are the ones that treat the default trust store as a fire-and-forget setting.

How Certificate Authorities Create SSL Trust on Your Devices

Operating systems ship with a root certificate store containing trusted CAs. Microsoft, Apple, and Google each maintain their own root programs, which define which CAs their platforms trust by default and which get removed when violations occur.

When a browser or application opens an SSL/TLS connection, it traces the server’s certificate up a chain to a root CA in the device’s trust store. If the chain terminates at a trusted root, the connection proceeds with no warning, no error, and no prompt to the user.

Root CAs enter a device’s trust store through several paths, each with a different risk profile:

• OS updates, which add or remove root CAs as vendors revise their root programs
• Third-party software installers, which sometimes inject their own CA certificates during setup
• Mobile device management (MDM) configuration profiles, which allow administrators to distribute approved CAs across managed endpoints
• Manual administrator action, which requires proper change logging to avoid undocumented additions

The hierarchy matters when something goes wrong. A root CA issues intermediate CAs, which sign the leaf certificates your users encounter on websites and in applications. A compromised root invalidates every certificate in its chain, which is why root CA trust decisions carry more security weight than any other certificate in the store.

Default Trust Stores on Windows, Android, and Business Endpoints

The platform mix across your fleet determines where your audit effort needs to go first:

• Windows: Windows manages the trust store through Certificate Manager (certmgr.msc). Root CA updates distribute via Windows Update or Group Policy, giving administrators a direct path to fleet-wide control.
• Android: Android divides trusted credentials into system-level and user-installed certificates, accessible under Settings > Security > Trusted Credentials. User-installed certificates on company-issued Android devices are one of the most common and underexamined risk vectors in business fleets.
• macOS and iOS: macOS and iOS manage certificates through Keychain Access and configuration profiles. iOS restricts user-installed CAs by default unless an MDM configuration explicitly permits them, which makes it more forgiving than Android for company-issued devices.
• BYOD endpoints: Bring-your-own-device environments introduce trust stores IT cannot directly inspect or control. Without a formal policy governing BYOD certificate hygiene, these devices represent a growing gap in your fleet’s security posture.

What Trusted Credentials to Disable or Remove

Not every CA in your trust store poses equal risk, but these categories consistently warrant removal from business devices:

1. User-installed certificates not deployed through IT policy. Any certificate in the “User” store on a company device that IT did not push there should come out immediately. Then investigate how it arrived and whether other devices in the fleet are affected.
2. CAs from vendors or jurisdictions your organization has no relationship with. If there is no business reason to trust a CA, it has no place in your trust store.
3. CAs publicly distrusted by major browser vendors. Mozilla, Google, and Apple have each removed CAs from their root programs for documented violations, including certificate mis-issuance and failed audits. If a CA has been removed from a major root program, remove it from your fleet.
4. Root certificates installed by third-party software for SSL inspection. Some applications inject a CA during setup to intercept and inspect encrypted traffic for content filtering or logging purposes. Without explicit IT authorization and documentation, these certificates represent an unauthorized position in your certificate chain.
5. Expired certificates still present in the active store. Expired CAs provide no trust value and generate unnecessary noise in security audits. Remove them.

Rogue Certificate Authorities: The Real Threat to Business Networks

A rogue CA is any certificate authority in your trust store that IT did not intentionally deploy. The source is typically a malicious software bundle, a deceptive installer, or malware with sufficient access to write to the certificate store.

Once a rogue CA is trusted, it can sign fraudulent certificates that your devices accept without any browser warning, SSL error, or visible indication that the connection has been intercepted.

Two real incidents illustrate how this plays out. In 2011, the DigiNotar breach gave attackers the ability to issue fraudulent SSL certificates for major domains, including Google.com. Those certificates were used to intercept traffic from over 300,000 users, primarily in Iran, according to EFF’s analysis of the Fox-IT breach investigation.

Four years later, Lenovo shipped consumer laptops with pre-installed adware called Superfish. The adware injected a self-signed CA into the Windows trust store, exposing every SSL connection those machines made to third-party interception without triggering any warning.

For Chicagoland organizations managing dozens or hundreds of endpoints, the fleet multiplier risk is significant. One compromised device’s trust store affects every encrypted connection that device makes:

• Banking and financial portals
• HR systems and employee data
• Cloud platforms and SaaS applications
• Internal line-of-business tools

Chicago cybersecurity services add the monitoring layer your endpoint environment needs to catch unauthorized certificate additions before they become incidents.

How to Audit Trusted CAs on Company Devices

A certificate trust audit follows the same logic on every platform: enumerate what is present, compare it against a known-good baseline, and investigate anything that does not belong.

Windows

Open certmgr.msc or run Get-ChildItem Cert:\LocalMachine\Root in PowerShell to list all trusted root CAs on a machine. Then cross-reference your installed roots against Mozilla’s CA Certificate Program, which tracks distrust announcements and CA removal actions from all major vendors as they occur.

Android

On company-issued Android devices, navigate to Settings > Security > Trusted Credentials and open the “User” tab. Any certificate there that IT did not deploy through a management profile requires investigation and removal before the device returns to production use.

Fleet-Wide Practices

Three steps that make recurring audits sustainable at scale:

• Document a baseline. Capture a known-good trust store snapshot after each audit cycle. Future reviews become a comparison exercise: current state against baseline, flagging new additions for investigation.
• Monitor distrust announcements. Check installed CAs against browser vendor distrust records before each audit cycle so recently revoked roots do not persist on devices longer than necessary.
• Prioritize high-risk endpoints. Finance workstations, HR systems, and devices with access to regulated data, whether payment records or patient information, get audited before general workstations.

Enforcing Certificate Trust Policy Across Your Fleet

Auditing trust stores once corrects today’s state. Policy enforcement is what prevents unauthorized CAs from accumulating between audit cycles.

• Group Policy (GPO) on Windows domain environments lets administrators push an approved CA list to every managed machine and block certificates outside that approved set. Policy changes propagate on Group Policy refresh without requiring manual intervention on individual devices.
• MDM platforms extend certificate management across Windows, macOS, iOS, and Android endpoints from a single management console. Approved CAs deploy on device check-in; revocations push the same way, automatically.
• Configuration profiles on company-issued mobile devices block end users from installing their own certificates, which closes the most common vector for unauthorized CA additions on phones and tablets.
• Review cadence: Update the certificate trust policy at new software vendor onboarding, after any security incident, and at minimum annually as part of standard endpoint hygiene practice.

For Chicagoland businesses running a mixed fleet of Windows workstations, company-issued mobile devices, and BYOD endpoints, managing certificate policy in-house eventually means adding dedicated headcount. A managed IT services provider gives you the tooling and ongoing expertise to keep your trust policy current without that overhead.

Close the Certificate Trust Gap

When certificate trust management across your fleet becomes a managed risk rather than a recurring crisis, your team can focus on the work that actually moves the business forward.

LeadingIT provides managed IT and cybersecurity services to businesses across the Chicagoland area, including endpoint management, MDM configuration, certificate trust policy enforcement, and security monitoring. We work with organizations between 25 and 250 employees that need consistent, proactive security practices without building an in-house security team to maintain them.