This is a canonical question about the different types of Microsoft Certificate Authority

I'm looking for an information about difference between Microsoft ADCS Enterprise CA and Standalone CA?

When and where I should use each CA type? I tried to google this question and found only one answer that Standalone CA does not enjoy Active Directory. What I should take into consideration before choosing one?

3 Answers 3


There is significant difference between Standalone and Enterprise CAs and each have its usage scenario.

Enterprise CAs

This type of CAs offer the following features:

  • tight integration with Active Directory

When you install Enterprise CA in AD forest, it is automatically published to AD and each AD forest memeber can immediately communicate with CA to request certificates.

  • certificate templates

Certificate templates allows enterprises to standatize issued certificates by their usages or whatever else. Administrators configure required certificate templates (with appropriate settings) and put them to CA for issuance. Compatible recipients don't have to bother with manual request generation, CryptoAPI platform will automatically prepare correct certificate request, submit it to CA and retrieve issued certificate. If some request properties are invalid, CA will override them with correct values from certificate template or Active Directory.

  • certificate autoenrollment

is a killer feature of Enterprise CA. Autoenrollment allows to automatically enroll certificates for configured templates. No user interaction is required, everything happens automatically (of course, autoenrollment requires initial configuration).

  • Key Archival

this feature is underrated by systems administrators, but is extremely valuable as a backup source for user encryption certificates. If private key is lost, it can be recovered from CA database if necessary. Otherwise, you will loose access to your encrypted content.

Standalone CA

This type of CA can't utilize features provided by Enterprise CAs. That is:

  • No certificate templates

this means that every request must be manually prepared and must include all required information to be included in the certificate. Depending on certificate template settings, Enterprise CA may require only key information, the rest info will be automatically retrieved by CA. Standalone CA won't do that, because it lacks information source. The request must be literally complete.

  • manual certificate request approval

Since Standalone CA do not use certificate templates, every request must be manually verified by a CA manager to ensure that request does not contain dangerous information.

  • no autoenrollment, no key archival

Since Standalone CA do not require Active Directory, these features are disabled for this type of CAs.


Although, it may look that Standalone CA is a dead end, it isn't. Enterprise CAs are best suited to issue certificate to end entities (users, devices) and is designed for "high volume, low cost" scenarios.

On the other hand, Standalone CAs are best suited for "low volume, high cost" scnearios, including offline ones. Generally Standalone CAs are used to act as Root and Policy CA and they issue certificates only to other CAs. Since certificate activity is quite low, you can keep Standalone CA offline for a reasonable large time (6-12 months) and turn on only to issue new CRL or sign new subordinate CA certificate. By keeping it offline, you enhance its key security. Best practices suggest to never attach Standalone CAs to any network and provide good physical security.

When implementing enterprise-wide PKI, you should focus on a 2-tier PKI approach with offline Standalone Root CA and online Enterprise Subordinate CA that will operate in your Active Directory.


Obviously the AD integration as you already mentioned is a big one. You can find a brief comparison here. The author summarizes the differences as follows:

Computers in a domain automatically trust certificates that enterprise CAs issue. With standalone CAs, you must use Group Policy to add the CA's self-signed certificate to the Trusted Root CAs store on each computer in the domain. Enterprise CAs also let you automate the process of requesting and installing certificates for computers, and if you have an enterprise CA running on a Windows Server 2003 Enterprise Edition server, you can even automate certificate enrollment for users with the auto-enrollment feature.

  • Unfortunately, the author in the referenced article is incorrect. When installing Standalone Root CA with domain account, CA certificate is published to Active Directory. Sorry, can't post answer here.
    – Crypt32
    Jan 15, 2017 at 23:54
  • @Crypt32 You seem well placed to answer the question, why you can't post there ?
    – yagmoth555
    Jan 16, 2017 at 19:13
  • 1
    Because it was closed at that moment.
    – Crypt32
    Jan 16, 2017 at 19:26

Enterprise CA provides usefulness to enterprises (but requires access to Active Directory Domain Services):

  • Uses Group Policy to propagate its certificate to the Trusted Root Certification Authorities certificate store for all users and computers in the domain.
  • Publishes user certificates and certificate revocation lists (CRLs) to AD DS. In order to publish certificates to AD DS, the server that the CA is installed on must be a member of the Certificate Publishers group. This is automatic for the domain the server is in, but the server must be delegated the proper security permissions to publish certificates in other domains.
  • Enterprise CAs enforce credential checks on users during certificate enrollment. Each certificate template has a security permission set in AD DS that determines whether the certificate requester is authorized to receive the type of certificate they have requested.
  • The certificate subject name can be generated automatically from the information in AD DS or supplied explicitly by the requester.

    More info about Stand-alone and Enterprise ADCS CA.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .