Tim Beasley Senior Incident Response Consultant

In this article series, we’ve examined how permissions in groups such as Backup Operators and Account Operators can be exploited. In this post, we’ll explore how trust figures into Active Directory group risks.

Cryptographic Operators is one of those groups that most defenders either ignore completely or mentally file under “probably not important.” That’s a big mistake.

At first glance, Cryptographic Operators doesn’t look scary. Microsoft describes it simply: Members are authorized to perform cryptographic operations.

  • It’s a built-in local group in the Builtin container.
  • It has no default members.
  • It has no default user rights assigned out of the box.

That bland description is exactly why it gets overlooked.

The problem isn’t that Cryptographic Operators looks like Domain Admins. It doesn’t. The problem is that it sits dangerously close to the systems that define trust.

And in Windows, trust is everything.


What is the Cryptographic Operators group?

Microsoft introduced the Cryptographic Operators built-in group to represent the Crypto Officer role and to control certain cryptographic configuration tasks in Windows environments using Cryptography API: Next Generation (CNG). In Common Criteria or FIPS-related scenarios, members of Cryptographic Operators can configure cryptographic settings that ordinary users can’t, including specific IPsec cryptographic parameters.

That matters because the provider model underneath Windows crypto isn’t just some academic plumbing. Microsoft’s cryptographic providers implement algorithms, generate keys, provide key storage, and authenticate users, and both Active Directory Certificate Services (AD CS) and certificate enrollment rely on CryptoAPI and CNG.

In other words, this is not “just another weird built-in group.”

It lives next to the machinery that helps decide how keys are created, where they live, and how authentication, signing, and encryption workflows function.

And when it’s exploited, you may be facing game over.


Why this AD group becomes dangerous faster than people think

A lot of people hear “cryptographic operations” and assume that means some narrow, harmless backend task.

That’s the wrong mental model.

If your environment uses AD CS, smart cards, IPsec, hardware security modules, or software and hardware key storage providers, you’re already operating in a space where cryptographic configuration is tied directly to identity, authentication, and trust decisions.

Semperis already treats Cryptographic Operators as a known Tier 0 group across multiple real customer environments, not as a low-value legacy curiosity.

That should tell defenders something important: Even if the default description looks harmless, the blast radius is not.


Realistic defender concerns after compromise

The danger with Cryptographic Operators is more contextual than something like Backup Operators.

Backup Operators screams abuse.
Cryptographic Operators whispers it.

That’s worse.


1. Crypto policy tampering in the environments that actually use it

Microsoft’s own documentation and historical guidance tie this group to CNG configuration and to IPsec cryptographic settings in Common Criteria mode, including the ability to set or modify specific main-mode cryptographic parameters that standard users cannot change.

If an attacker lands on an identity that has this kind of responsibility in a hardened environment, you should assume they are now operating on the trust-policy plane (aka Tier 0), not just on an endpoint.

That’s where subtle changes become strategic changes.


2. Proximity to PKI and key-management workflows

Key Storage Providers (KSPs) are responsible for storage and retrieval of cryptographic keys, and when AD CS is installed, administrators explicitly choose a provider to manage the CA private key. (…or they just “next their way to success” during install…)

At the same time, Microsoft’s crypto provider model underpins certificate enrollment and AD CS operations more broadly.

So while Cryptographic Operators membership does not automatically mean instant access to every private key, it absolutely means you should scrutinize any environment where that group is populated, because the role sits adjacent to the systems that manage trust anchors and signing keys.

That is not a place where “probably fine” is an acceptable security decision.


3. Hidden persistence and weak visibility

Microsoft documents that Cryptographic Operators has no default members and isn’t protected by AdminSDHolder—while also indicating that management of the group shouldn’t be delegated to non-service admins.

That combination should make you uncomfortable.

It means this isn’t one of the obvious protected groups defenders obsess over, yet it’s still considered sensitive enough that Microsoft explicitly says “do not its management to lower-trust administrators.”

That makes it a perfect blind spot.


4. Private-key operational surfaces defenders rarely inspect well

For software-backed providers, Windows commonly stores machine-level private keys under paths such as C:\ProgramData\Microsoft\Crypto\Keys for CNG KSPs and C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys for CryptoAPI CSPs.

I’m not saying Cryptographic Operators membership alone grants blanket access to those files.

I am saying that if you’re dealing with accounts trusted to operate around crypto configuration, providers, certificate services, and key workflows, those are the exact surfaces defenders should be reviewing for ACL mistakes, provider misuse, and operational abuse.


What defenders should monitor

Start with one simple question: Why is anyone in this group at all?

Microsoft says Cryptographic Operators has no default members. So if it’s populated, that should trigger immediate review.

From there, watch for:

  • Membership additions and removals. The Cryptographic Operators group should usually stay empty and any change is operationally meaningful.
  • Changes to IPsec or cryptographic policy in environments using Common Criteria or FIPS-related controls, especially when those changes are made by identities that are not part of a tightly controlled crypto-admin workflow.
  • Activity on CA servers, enrollment servers, Smart Card infrastructure, and systems using HSM or software KSP/CSP integrations; those workflows rely on the same provider stack that this group was created to help govern.
  • ACL and access reviews on software-backed key locations such as MachineKeys and Crypto\Keys, because defenders often monitor certificate issuance but neglect the underlying key storage layer.

What to do about risks in Cryptographic Operators

The preferred recommendations are the same ones I’ve made for other AD groups:

Keep the group empty. And monitor any changes to the group membership.

If Microsoft says the group has no default members and your own Tier 0 logic already classifies it as sensitive, there should be a very high bar before anyone is placed in it.

If you believe you need it, prove it.
Specifically:

  • Document the exact workflow that requires membership.
  • Identify the exact servers, providers, HSM integrations, smart-card services, or IPsec policies involved.
  • Treat the account as Tier 0 or Tier 0-adjacent.
  • Restrict where it can log on.
  • Review the CA and provider configuration around it.
  • Monitor the group as you would any other trust-defining admin surface.

If the account is trusted to operate the systems that define cryptographic trust, then by definition it’s operating in an area of the environment where one mistake can become everyone’s problem.


Shine a spotlight on your trust-plane identities

Cryptographic Operators is dangerous precisely because it doesn’t look dangerous.

  • Its default description is short.
  • Its membership is often empty.
  • Its name doesn’t trip the same alarms as “Admins” or “Operators” groups with louder permissions.

But Microsoft ties it to cryptographic configuration authority, the Windows provider model behind keys and certificates, and specific high-trust IPsec and CNG scenarios.

And Semperis assessment outputs already treat it as a known Tier 0 group in real environments.

That means mature defenders should stop treating Cryptographic Operators like harmless background noise.

If an identity can influence the cryptographic trust plane, it’s not a low-privilege identity. It’s a trust-plane identity.

And trust-plane identities deserve Tier 0 thinking.

Until next time…follow the conversation about Cryptographic Operators on LinkedIn.

And to tap into expert help finding and closing gaps in your AD security groups, reach out for an Active Directory Security Assessment. We’re here for you.


Related resources