PKI & CLM
Frequently Asked Questions (FAQ)

A PKI (Public Key Infrastructure) is a trust infrastructure for secure digital communication. It makes it possible to reliably verify the digital identities of people, devices, servers, or applications using certificates and to manage cryptographic keys in a controlled manner. A PKI therefore provides a trusted foundation for authentication, encryption, and digital signatures.

PKI stands for “Public Key Infrastructure.” It refers to an infrastructure consisting of technical components, processes, and policies used to issue, manage, validate, and, when necessary, revoke cryptographic keys and digital certificates.

A PKI is needed to reliably associate public keys with specific identities and to provide trusted proof of that association. This makes it possible to securely authenticate people, devices, servers, and applications and to protect digital communications.

Public Key Cryptography uses a mathematically related key pair: a public key and a private key. The private key remains secret, while the public key can be distributed.

Depending on the cryptographic method, the key pair can be used, for example, to encrypt data or to create and verify digital signatures. The private key is the particularly sensitive foundation of the corresponding digital identity.

Public Key Cryptography refers to cryptographic methods that use public and private keys. A PKI adds a trust infrastructure consisting of certification authorities, certificates, policies, and processes. This allows public keys to be reliably associated with identities and securely managed even in large IT environments.

Digital certificates are a central component of a PKI. They associate a public key with a specific identity, such as a person, server, application, or device. The Certification Authority confirms this association using its digital signature.

An X.509 certificate is a standardized digital certificate that associates a public key with an identity. Among other things, it contains information about the certificate holder, the public key, the issuing Certification Authority, the validity period, and the intended purposes of the certificate.

A digital certificate confirms the association of a public key with a specific identity or entity. Depending on the certificate, this may be a person, device, server, application, or organization.

A digital signature is created using a private key and can be verified using the corresponding public key. This makes it possible to determine whether the signed data has been modified since it was signed and whether the signature was created using the corresponding private key.

The central components of a PKI include Certification Authorities (CAs), Registration Authorities (RAs) where applicable, digital certificates, revocation information, as well as policies and processes for issuing, managing, renewing, and revoking certificates. The CA structure often consists of a Root CA and one or more subordinate CAs.

The Root CA is the highest trust authority in a hierarchical PKI. Its certificate is self-signed and serves as the trust anchor for the Certification Authorities below it.

Because the Root CA’s private key requires a particularly high level of protection, the Root CA is often operated offline in environments with high security requirements and activated only for a limited number of controlled operations.

A Sub CA is a Certification Authority whose certificate has been signed by a higher-level CA. Depending on the PKI structure, it can issue certificates for additional subordinate CAs or end-entity certificates for users, devices, servers, and applications.

An Offline Root CA is used when particularly high requirements apply to protecting the central trust anchor of a PKI. Its private key remains disconnected from the network during normal operations.

The Root CA is activated only for a limited number of controlled operations, such as issuing or renewing Sub-CA certificates or making structural changes to the PKI. This model is particularly common in security-critical and regulated environments.

A Registration Authority (RA) performs tasks that take place before the actual certificate issuance. For example, it verifies identities and request data, implements approval processes, and forwards approved certificate requests to the responsible Certification Authority. This makes it possible to organizationally separate verification and certificate issuance.

A PKI is relevant for companies and organizations that want to reliably secure digital identities and automate certificate-based processes. Typical use cases include authenticating users, devices, servers, and applications, securing network access, encrypted communication, digital signatures, and IoT and machine-to-machine communication.

A PKI is particularly relevant in larger or heterogeneous IT environments, as well as in regulated industries and critical infrastructure. Regulatory requirements such as NIS2 or DORA may include requirements related to cryptography, access protection, risk management, and traceability, and a professionally operated PKI can help organizations address these requirements. The specific need for and design of a PKI always depends on the organization’s particular use case and regulatory requirements.

Companies can use different models depending on their use case. Publicly trusted certificates are obtained from Public CAs or trust centers and are used, for example, for publicly accessible websites, servers, or services.

For private certificates, companies can operate their own PKI or use a Managed PKI service. With an On-Premises solution, the PKI remains within the company’s own infrastructure and can be closely integrated into the existing IT and security architecture. With a Managed Service, a specialized provider assumes key responsibilities for the secure operation of the PKI and CLM.

With MTG Corporate PKI & CLM, MTG offers both an On-Premises solution and, together with our partner DARZ, a Managed PKI & CLM offering. The most appropriate operating model depends in particular on security and compliance requirements, available resources, integration requirements, and the desired level of in-house operation.

An in-house On-Premises PKI is particularly useful when companies require a high degree of control over infrastructure, processes, key material, and integrations, or when they intentionally want to retain responsibility for PKI operations themselves.

A Managed Service can be a suitable alternative if technical and regulatory requirements can also be met through an externally operated service. Key factors include an appropriate security and operating model, clearly defined responsibilities, suitable certifications, auditability, and controlled third-party management. Especially where regulatory requirements apply, the company remains responsible for assessing and managing outsourced risks.

With DARZ Managed PKI & CLM powered by MTG, we provide highly available operations across two certified data centers in Germany. Whether a Managed Service meets a company’s specific regulatory requirements must always be assessed based on the individual use case and applicable requirements.

With an On-Premises PKI, the PKI is operated within the company’s own infrastructure and integrated into the existing IT and security architecture. Operation and management can be handled by the company’s own team or by MTG.

Alternatively, MTG Corporate PKI & CLM can be obtained as a Managed Service through our partner DARZ. The service is operated with high availability at locations in Darmstadt and Frankfurt am Main, Germany. By default, the customer environment is connected through a site-to-site VPN; alternatively, a secured connection over the public Internet is possible.

The most suitable model depends on requirements related to security, compliance, integration, data sovereignty, and the availability of internal PKI resources.

A private certificate is a digital certificate issued by a private or enterprise-controlled trust infrastructure. It is trusted only by systems on which the corresponding private CA has been configured as a trust anchor.

Private certificates are suitable, for example, for internal servers and applications, users and devices, VPN and network access, machine-to-machine communication, or IoT environments. With a Corporate PKI, companies can issue and manage these certificates in accordance with their own security policies.

A public certificate is a certificate issued by a publicly trusted Certification Authority (Public CA). The CA’s root certificates are included as trusted roots in widely used operating systems, browsers, and applications.

Public certificates are particularly necessary when systems or services need to be trusted by external endpoints that are not managed by the company, for example, publicly accessible websites or Internet services.

The key difference lies in the trust model. With private certificates, the company or operator of the private PKI determines which systems trust its CA. They are therefore particularly suitable for controlled enterprise and infrastructure environments.

Publicly trusted certificates, by contrast, are issued by Public CAs whose trust anchors are already included in widely used operating systems and applications. This means external systems can trust a certificate without first having to install the company’s own CA.

Many companies require both types of certificates in parallel. MTG CLM makes it possible to centrally manage private certificates from the company’s own PKI as well as certificates from connected Public CAs.

With an On-Premises PKI & CLM, MTG Corporate PKI & CLM is operated within the company’s own infrastructure and fully integrated into the existing IT and security architecture. This allows companies to determine the level of control they want to maintain over systems, processes, and key management.

With DARZ Managed PKI & CLM powered by MTG, PKI and Certificate Lifecycle Management are provided as a service. Operations are highly available 24/7 across two certified data centers in Darmstadt and Frankfurt am Main, Germany. The MTG CA keys are protected in certified Hardware Security Modules.

Both operating models are based on MTG Corporate PKI & CLM. The appropriate option depends in particular on regulatory requirements, available internal resources, integration requirements, and the desired level of responsibility for PKI operations.

Certificate Lifecycle Management (CLM) refers to the centralized management of digital certificates throughout their entire lifecycle—from request and issuance to use, monitoring, renewal, and revocation. With MTG CLM, companies can centrally control, automate, and transparently manage these processes.

As the number of digital certificates increases, the effort required to manage them also grows. Without a centralized CLM, expired or insufficiently renewed certificates can lead to outages and security risks.

MTG CLM provides transparency into existing certificates, their status, validity periods, and locations of use, and helps companies automate certificate processes and identify risks at an early stage.

A CLM supports the entire lifecycle of digital certificates. This includes certificate requests, issuance through connected Certification Authorities, deployment, monitoring, renewal, and revocation.

MTG CLM enhances these functions with Certificate Policies, monitoring and reporting, notifications, role and rights management, and various automation and integration interfaces.

The lifecycle of a certificate includes all phases from request and issuance through active use and monitoring to renewal, revocation, or decommissioning. MTG CLM makes it possible to centrally control these steps and document them in a traceable manner.

A CLM reduces the manual effort involved in certificate management and helps minimize risks caused by expired, unknown, or incorrectly managed certificates. At the same time, it improves transparency into certificate inventories and responsibilities.

With MTG CLM, companies can centrally manage large and heterogeneous certificate environments and automate many recurring processes.

A CLM is particularly relevant for companies that use a large or growing number of digital certificates and want to centrally manage validity periods, responsibilities, and processes.

A CLM is especially useful in environments with multiple PKIs, different business units, heterogeneous IT infrastructures, or increased requirements for security, compliance, and auditability. Companies that want to further automate their certificate processes also benefit from centralized Certificate Lifecycle Management.

A CLM is particularly worthwhile when the number of certificates is growing, multiple Certification Authorities or PKIs are in use, responsibilities are distributed across teams, or requirements for automation, security, and compliance are increasing.

Automated processes can also significantly reduce administrative effort when certificate validity periods are short or when a large number of machine, server, or device identities must be managed.

A CLM provides transparency into the certificate inventory, reduces manual tasks, and supports standardized and automated certificate processes. This helps reduce sources of error and outage risks while improving the documentation and auditability of certificate processes.

MTG CLM provides features such as monitoring and reporting, notifications, Certificate Policies, and granular role and rights management.

MTG CLM centrally provides certificates and relevant information such as validity period, status, and location of use. With Certificate Discovery, existing certificates within the infrastructure can also be detected and added to the central inventory.

This gives companies a better overview of their certificate landscape and helps them identify risks such as unknown or soon-to-expire certificates at an early stage.

MTG CLM monitors certificate validity periods and status and can automatically provide notifications about upcoming expirations or required actions. In combination with automated renewal processes, certificates can be replaced in a timely manner.

This can significantly reduce the risk of unplanned outages caused by expired certificates.

Automation is a central component of Certificate Lifecycle Management. It reduces manual work, minimizes sources of error, and makes it possible to efficiently manage even large certificate inventories.

With MTG CLM, certificate processes can be integrated into existing IT and deployment workflows using standardized PKI protocols, APIs, and additional automation interfaces.

MTG CLM supports common PKI automation protocols such as ACME, EST, CMP, and SCEP, as well as a comprehensive REST API. The MTG ERS CLI Client is also available for scripting and automated workflows.

Using the REST API and CLI, MTG CLM can also be integrated with Infrastructure-as-Code and automation tools such as Ansible and Terraform, as well as CI/CD processes.

MTG CLM provides a granular role and rights model. This allows responsibilities to be separated and access rights to be assigned in accordance with organizational and security requirements.

The authorization model can also support self-service scenarios in which users manage specific certificates themselves within the permissions assigned to them.

Certificate Policies are centralized rules and templates for requesting and issuing certificates. They define, for example, which Certificate Provider is used, which validity periods, key lengths, or intended uses are permitted, and which additional requirements apply to a certificate request.

This helps standardize certificate requests and consistently enforce security policies.

MTG CLM helps companies implement certificate processes in a centralized, traceable, and controlled manner. Features such as role and rights management, Certificate Policies, monitoring, reporting, and auditability provide a structured foundation for this purpose.

Whether specific regulatory requirements are met, however, always depends on the overall technical and organizational design of the PKI and security environment.

MTG CLM can help companies address regulatory and internal security requirements by transparently recording certificate inventories and ensuring that processes are standardized, controlled, and traceable.

However, a CLM alone does not establish regulatory compliance. Compliance always depends on the interaction of technical measures, processes, responsibilities, and the selected operating model.

Yes, MTG CLM is designed to centrally integrate different Certification Authorities and Certificate Providers. This makes it possible to manage certificates from different private and public PKI environments through a single centralized platform.

Supported providers include MTG CARA, Microsoft CA, and various Public CA providers. The available functions may differ depending on the connected Certificate Provider.

Yes, MTG CLM can centrally manage both private and publicly trusted certificates. Private certificates can, for example, be provided through MTG CARA or a connected Microsoft CA.

Direct Certificate Provider integrations are available for public certificates. These currently include, among others, GlobalSign, Deutsche Telekom Security via PCSP, and selected Sectigo certificates via PSW.

MTG CLM provides various integrations for existing enterprise and PKI environments. These include Microsoft PKI (AD CS), various Public CAs, Microsoft Active Directory, Microsoft Entra ID, Keycloak, and Microsoft Intune.

Standardized PKI protocols as well as REST API and CLI interfaces are also available for integration with applications, automation platforms, and custom processes.

The Microsoft CA Connector can be used to connect an existing Microsoft PKI based on AD CS to MTG CLM. The Microsoft CA remains the issuing Certification Authority, while certificates can be requested and managed through MTG CLM.

In the technical documentation, this integration is referred to as the Microsoft CA Certificate Provider. This allows companies to use MTG CLM functionality without first having to replace their existing Microsoft PKI.

The MTG Autoenrollment Connector makes it possible to replace Microsoft AD CS as the issuing PKI with MTG CARA while continuing to use established Windows autoenrollment mechanisms. Existing processes such as autoenrollment, Group Policies, and Microsoft certificate templates can be integrated into the new PKI structure.

The migration requires corresponding configuration steps, for example for Certificate Templates, Enrollment Policies, Group Policies, and distribution of the new CA certificates.

Hardware Security Modules (HSMs) protect particularly sensitive cryptographic key material and perform cryptographic operations in a specially secured environment.

MTG CLM supports the integration of HSMs and Crypto Modules through standardized interfaces such as PKCS#11. Both On-Premises HSMs and Cloud HSM offerings can be integrated. In combination with MTG CARA, the private keys of Certification Authorities in particular can be protected in an HSM.

A PKI provides the technical trust infrastructure. The Certification Authority within the PKI issues certificates and cryptographically signs them.

A CLM complements the PKI with centralized management and automation of certificate processes throughout the entire lifecycle. With MTG Corporate PKI & CLM, we combine MTG CARA as the Certification Authority with MTG CLM for lifecycle management and automation.

Yes, a CLM can also be useful for smaller companies, particularly when the number of certificates is growing or certificates are used for business-critical systems. Even a manageable number of manually administered certificates can increase operational effort and the risk of outages.

The key factors are therefore less about company size and more about the number, criticality, and diversity of certificates in use, as well as the desired level of automation.

The number of digital certificates and machine identities continues to grow due to cloud infrastructures, IoT, mobile devices, microservices, Zero Trust architectures, and increasing automation. At the same time, requirements for security, transparency, and traceability are increasing.

Centralized Certificate Lifecycle Management helps companies manage this growing certificate landscape in a controlled manner and automate certificate processes.

Keycloak provides centralized identity and access management within MTG ERS® applications. This allows users to be authenticated centrally and login processes to be managed across different MTG ERS® components.

Existing identity and directory services can be connected through Keycloak. Supported systems include Microsoft Active Directory and Microsoft Entra ID. Keycloak also enables Single Sign-On, different authentication methods, and centralized user identity management. MTG Corporate PKI & CLM uses Keycloak as its integrated identity management solution.

Yes, existing certificates can be integrated into the centralized certificate management system. Certificates can be imported manually or, where the technical requirements are met, automatically through Certificate Discovery.

Public certificates in particular can be easily integrated, for example through scanning mechanisms.

The platform is designed so that certificates can be created even without in-depth PKI expertise. Much of the technical complexity remains in the background, while the user interface supports simple, secure, and practical operation.

This allows companies to start creating certificates directly and, if required, rely on the additional support of experienced PKI experts. A supporting video is also available.

With MTG CLM, companies can centrally monitor the status and validity periods of their certificates. A configurable notification system provides information about relevant events and upcoming certificate expirations, allowing renewal activities to be initiated in time.

Dashboards as well as search and filter functions provide a quick overview of the certificate inventory. Results can be exported for further processing. Relevant activities are also logged so that changes and events can be traced.

Role and permissions management in MTG CLM can be centrally controlled and provides detailed options for assigning permissions to CLM users. For example, permissions can be restricted to specific Realms or individual Policies.

These settings can be defined for individual users as well as entire business units or specific policies. This makes it possible to align access rights for digital certificates with the organization’s structure.

The individual areas can also be structured flexibly. So-called Realms can, for example, be organized by department, user group, or hierarchy.

Different user roles can also be configured, such as read-only roles or roles with extended certificate configuration permissions. Notification rules can likewise be customized. The user interface reflects the assigned settings and displays only the functions and content intended for the respective user.

Policies consolidate the rules required to configure different types of certificates. This helps ensure that entries are complete, correct, and compliant. For example, tailored templates can be defined for email certificates, server certificates, connected hardware, or mobile devices.

Policies can be used to specify approved algorithms and permitted key material. They can also define certificate validity periods, whether certificate requests require manual or automatic approval, and whether a four-eyes approval principle is required.

Because different use cases have different requirements, the applicable conditions are defined through Policies for each specific scenario. Every MTG PKI instance is therefore delivered with a selection of predefined Policies for standard scenarios that can be adopted and adjusted as needed.

Additional Policies can be created based on existing templates, for example by cloning a Policy and then modifying selected parameters. Policies can also be created entirely from scratch.

If specialized templates are required or existing templates need to be adapted, this can be implemented as part of MTG consulting services. Our PKI experts support customers in designing and configuring suitable templates.

Yes, every MTG PKI & CLM instance comes with a selection of predefined Policies for common standard scenarios. These templates can be used directly and adapted as needed.

The standard set includes Policy templates for SSL/TLS servers and ACME for issuing typical TLS certificates for web servers. Templates for Machine, SCEP, EST, and CMP are also available and can be used for certificates on network devices such as switches, routers, or printers.

Templates for Person and S/MIME Email are also included, for example for secure email communication, VPN access protection, or secure login. For Active Directory environments, Person Active Directory templates are available, for example for certificates issued to users through autoenrollment processes. Code Signing certificates are also available as a dedicated template.

If specific automation protocols were selected in the onboarding form, corresponding additional templates can be enabled.

New Policies can also be created based on existing templates, for example by cloning an existing Policy and modifying individual values. Policies can also be created entirely from scratch.

Yes, public certificates can be centrally requested and managed through MTG CLM. Direct integrations with different Public CAs and Certificate Providers are available for this purpose.

MTG CLM currently supports, among others, GlobalSign, PSW, and PCSP for Deutsche Telekom Security. Existing certificates can also be imported into MTG CLM.

The available certificate types, cryptographic methods, and automation interfaces depend on the respective Certificate Provider.

Different business units can be represented clearly and flexibly in MTG CLM using “Realms.” This allows access rights for digital certificates to be organized individually and aligned with the company’s organizational structure.

In combination with the role and permissions system, Realms also make it easy to provide department-specific self-service capabilities. Business units can perform defined tasks themselves without requiring a central PKI administrator for every action.

Yes, certificate requests can be configured for either manual or automatic approval. A four-eyes approval principle can also be implemented where required.

From an IT security perspective, using an HSM to protect private keys is highly recommended. A Hardware Security Module is particularly useful when cryptographic keys need strong protection against both software-based attacks and physical attacks on the underlying infrastructure.

HSMs generate, store, and manage cryptographic keys and therefore provide an important security foundation for protecting digital identities and sensitive data. In PKI environments in particular, they help ensure that highly sensitive key material is managed in a controlled and tamper-resistant manner.

Secure cryptographic key management is also relevant in many regulatory and standards-based contexts. The GDPR requires appropriate technical and organizational measures that take the state of the art into account, ISO/IEC 27001 defines requirements for an information security management system, and NIS2 introduces stronger cybersecurity risk-management requirements for affected organizations. In particularly sensitive environments, such as critical infrastructure, HSMs have therefore become an established industry practice.

Digital certificates enable secure authentication of users, devices, and systems and reduce reliance on purely password-based methods. The private key associated with the certificate serves as cryptographic proof of the respective digital identity.

Certificates can be used, for example, for Windows users and computers, mobile devices, network devices, or IoT systems. In combination with systems such as Active Directory, RADIUS, or Network Access Control, they can support secure access processes for Wi-Fi, VPN, and other corporate resources.

In Virtual Private Networks (VPNs), PKIs are used to authenticate the identities of communicating parties and establish secure, encrypted connections over public networks. This is particularly important for protecting sensitive corporate data when employees remotely access company resources, for example when working from home.

Digital certificates can also be used to secure connections between company locations. Certificate-based authentication can additionally improve scalability because certificates can be centrally managed and distributed even as the number of users or devices grows.

Network Access Control (NAC) refers to methods used to control access by users and devices to corporate networks. Digital certificates can be used as a secure authentication mechanism in this context.

A typical use case is certificate-based authentication using IEEE 802.1X. A device or user authenticates when accessing a LAN or Wi-Fi network, for example. An authentication service such as RADIUS verifies the identity and determines, based on the configured policies, whether network access should be granted.

Email certificates play an important role in protecting electronic communications, both within a company and when communicating with external partners. They enable emails to be digitally signed, making it possible to verify whether a message was signed by the stated sender and whether it has been modified since it was signed.

Certificates can also be used to encrypt emails and protect sensitive content from unauthorized access, for example when messages are transmitted over public networks. This can help protect confidential information such as personal data, contracts, or internal documents.

Publicly trusted certificates from Public CAs are often used for this purpose because they can also be validated and trusted outside the organization’s own network.

MTG CLM can also manage public S/MIME certificates for email encryption where required. In environments with a very large number of individual mailboxes, however, it can be more practical to manage certificate distribution and renewal through mechanisms built into an email security gateway, since these systems are optimized for high-volume processing. In such cases, MTG CLM can continue to be used centrally for other certificate processes, such as securing IT systems, devices, applications, or connections.

Yes, SSL/TLS web server certificates can also be used. They are a key component in securing web applications and web services. Certificates from a publicly trusted Certification Authority are typically used for Internet-facing services so that their trustworthiness can be validated by external users and systems.

Especially when managing a larger number of certificates, Certificate Lifecycle Management can significantly reduce administrative effort and help lower associated costs.

Mobile Device Management (MDM) platforms are used to centrally manage and secure mobile devices in enterprise environments. A PKI plays an important role in protecting communication between mobile devices, applications, users, and corporate services.

When a PKI is combined with integrated CLM, digital certificates can be deployed and managed on mobile devices much more efficiently. This supports secure and controlled access to corporate resources.

Yes, digital certificates can be used to sign electronic documents. A digital signature makes it possible to verify who signed a document and whether the document has been modified after it was signed.

MTG Corporate PKI & CLM can issue the required certificates or manage their lifecycle. The legal effect of a digital signature, however, depends on the signature method used, the certificate involved, and the applicable legal requirements.

In Code Signing, digital certificates make an important contribution to the security, integrity, and trustworthiness of software and firmware. They make it possible to identify the publisher of an application or software package. This allows users to verify that the software was actually published by the stated company rather than by an unknown or potentially malicious source.

When software is digitally signed, it is also possible to verify whether the code has been modified since it was signed. If changes are made afterward, the digital signature will no longer validate. Code Signing therefore helps protect users from manipulated or compromised software versions.

MTG Corporate PKI & CLM covers a broad range of common enterprise certificate use cases. These include servers and applications, users and endpoints, network components, IoT systems, Microsoft environments, and automated certificate processes.

Thanks to its modular architecture, different Certificate Providers, and numerous standardized interfaces, the solution can be flexibly adapted to new requirements. For specialized or industry-specific requirements, we work with our customers to determine how the respective use case can be implemented.

MTG Certificate Discovery can automatically identify existing and previously unknown certificates and import them into MTG CLM. Available mechanisms include network scans for TLS certificates, searches in LDAP or Active Directory, and Certificate Transparency logs.

The discovered certificates can be added to the centralized certificate inventory and evaluated based on validity period, status, and the cryptographic methods used. This gives companies greater transparency into certificates that were previously not managed centrally.

OCSP and Certificate Revocation Lists (CRLs) make it possible to determine whether a certificate has been revoked before the end of its regular validity period.

MTG Corporate PKI provides an OCSP Responder through the MTG Revocation Info Server. Full and delta CRLs can also be provided over HTTP or published to LDAP directories. This allows connected applications and systems to verify certificate revocation status.

Yes, a dedicated Root CA can be established as part of MTG Corporate PKI. The Root Certification Authority forms the highest trust authority within a PKI and is configured accordingly during deployment.

Its role is to use its private key to sign one or more subordinate Certification Authorities (Sub CAs). This establishes trust in the issuing CAs and ensures that certificates within the PKI are based on a reliable chain of trust.

Because a Root CA contains particularly sensitive cryptographic key material, protecting this material is essential. For this reason, the key material should be strongly secured and protected in Hardware Security Modules (HSMs).

Yes, multiple Root CAs can be configured with MTG Corporate PKI where required. This can be useful when different trust domains, organizational requirements, or cryptographic methods need to be separated.

For example, separate PKI hierarchies can be established for different security domains or for the phased introduction of new cryptographic methods.

An Offline Root CA is a special deployment model that involves additional manual operational effort. It is kept in a highly protected environment and activated only in exceptional cases, for example when additional Sub CAs need to be created or signed. Such operations are typically required only infrequently.

The key advantage of an Offline Root CA is the high level of protection against unauthorized access because it is not permanently available during normal operations.

An Offline Root CA is therefore particularly appropriate when very high IT security requirements apply, for example due to regulatory requirements or particularly high protection needs.

Yes, MTG Corporate PKI can be configured for your company with one or more Root CAs as well as one or more dedicated Sub CAs. This allows the PKI structure to be designed according to the respective business, organizational, or technical requirements.

Yes, MTG Corporate PKI & CLM logs relevant activities and changes so that certificate and administrative processes can be traced. The Audit Log supports internal controls, audits, and the analysis of security-relevant events.

The events and level of detail that are logged depend on the respective MTG ERS® component and its configuration.

Yes, comprehensive online documentation is available to all customers. It is publicly accessible and provides the relevant information required to use the solution.

MTG Corporate PKI & CLM can automate numerous certificate processes—from request and issuance through deployment and renewal—provided that the certificates originate from connected CAs. This currently includes MTG, Microsoft, GlobalSign, and Deutsche Telekom CAs.

A particular advantage for users of Microsoft CAs is that certificate processes outside traditional Microsoft environments can also be automated.

Examples of processes that can be automated include:

• Linux-based servers via ACME
• Network devices via SCEP, EST, and CMP
• Other systems via REST and the CLI Client
• Mobile devices via SCEP

Yes, the MTG Autoenrollment Connector can integrate MTG Corporate PKI into an existing Microsoft Active Directory environment. This allows Microsoft AD CS to be replaced as the issuing PKI by MTG CARA while established Windows autoenrollment mechanisms continue to be used.

The integration requires configuration of items such as certificate templates, Enrollment Policies, Group Policies, and distribution of the Root and Sub-CA certificates. MTG supports customers with planning and implementing this migration.

If you are looking for a modern PKI, you should definitely consider alternatives to Microsoft PKI (AD CS) as well. Based on our experience, there are two main reasons why companies move from the free Microsoft PKI to a more advanced solution:

Optimized Certificate Lifecycle Management: Modern PKI systems provide advanced and automated functions for managing the entire certificate lifecycle. These include issuance, renewal, revocation, and monitoring of certificates, significantly reducing administrative effort while improving security.

Expanded use cases with reduced effort: A modern PKI can support a wide range of use cases with considerably less effort. These include improved integrations, support for mobile devices, IoT security, and cloud environments. This gives your company the flexibility to respond quickly to new requirements and technological developments.

Additional detailed information and further answers on this topic are available in the linked article, which also contributed to the creation of these FAQs. It is important to carefully analyze your company’s specific requirements and future needs in order to select the most suitable PKI solution.

Yes, Microsoft CA (AD CS) can be integrated with MTG CLM. This allows you to continue using your existing Microsoft CA while extending its use to cross-platform, non-Windows-specific use cases, such as issuing Linux server certificates via ACME.

For companies that already operate a Microsoft PKI, there are two practical options:

Professional Package: Your Microsoft PKI remains in operation while MTG CLM manages the certificate-based processes. This enables centralized certificate management and automation.

Ultimate Package: When the CLM Autoenrollment Connector is used as part of the Ultimate Package, Microsoft PKI can be replaced by MTG PKI while established Active Directory-based autoenrollment processes continue to be used.

These options allow you to benefit from modern PKI and CLM capabilities while either retaining your existing infrastructure or migrating to MTG PKI.

Yes, an existing Microsoft PKI based on AD CS can be replaced with MTG Corporate PKI & CLM. The CLM Autoenrollment Connector enables MTG PKI to be integrated into an existing Microsoft Active Directory environment.

This allows established Windows autoenrollment processes for requesting, renewing, and deploying certificates to continue to be used. At the same time, MTG PKI supports additional use cases beyond traditional Windows environments.

The specific migration and integration effort depends on the existing AD CS configuration and the respective use cases. Depending on the environment, preparatory adjustments may therefore be required. MTG supports you with analysis, migration, and integration.

For evaluation purposes, a locally installable test simulator can optionally be provided for the Autoenrollment Connector. This allows the integration to be tested before connecting it to a production PKI.

Microsoft CA (AD CS) can manage certain certificate processes, but its broader lifecycle management capabilities are limited. Companies that require comprehensive Certificate Lifecycle Management should consider additional solutions such as MTG CLM.

A modern CLM provides several benefits, including:

• Web-based user self-services: Users can manage defined certificate processes themselves, reducing administrative effort.
• Flexible Certificate Policies: Certificate policies can be tailored to the specific requirements of the organization.
• Detailed configuration options: Roles and permissions can be precisely defined to support security and compliance requirements.

A modern CLM therefore helps companies manage certificate lifecycles more efficiently while improving the security and flexibility of their IT infrastructure.

Microsoft CA (AD CS) can manage certain certificate processes, but its capabilities for managing the complete certificate lifecycle are limited. Companies that require comprehensive Certificate Lifecycle Management may therefore need additional solutions such as MTG CLM.

A modern CLM provides benefits such as:

• Web-based user self-services: Users can independently manage defined certificate processes, reducing administrative effort.
• Flexible Certificate Policies: Policies can be tailored to the organization’s specific certificate and security requirements.
• Detailed configuration options: Roles and permissions can be precisely defined to meet security and compliance requirements.

With a modern CLM, companies can manage certificate lifecycles more efficiently while increasing the security and flexibility of their IT infrastructure.

Active Directory Certificate Services (AD CS) has existed since the Windows NT 4.0 era, although under different names. The Active Directory-based architecture was introduced with Windows 2000 Server.

AD CS is tightly integrated into the Windows ecosystem and continues to be widely used by companies and government organizations of all sizes. This long-standing integration and broad deployment demonstrate the reliability and stability of Microsoft PKI.

At the same time, the underlying technology and some implemented protocols do not always reflect the latest security requirements and innovations. To address modern security standards and benefit from current developments in cryptography and PKI technology, it may therefore make sense to supplement or replace Microsoft PKI with a more advanced solution.

A modern PKI can provide enhanced security functions, greater automation, and broader support for current and future use cases, particularly in hybrid and cloud-based environments.

With Active Directory Certificate Services (AD CS), each logical Certification Authority generally requires its own Windows Server instance. Depending on the size and structure of the organization, it can be useful to separate Certification Authorities by purpose and scope.

Many organizations also operate multiple Active Directory environments and CA hierarchies, which can result in a larger number of CA servers that must be managed, hardened, patched, maintained, and financed on an ongoing basis.

Modern PKI platforms can support multiple Certification Authorities within a consolidated platform, helping reduce the number of required server instances, simplify administration, and lower overall operating costs.

In Active Directory Certificate Services (AD CS), the Certification Authority database is implemented as a local CA-specific database. This limits the options for distributing or consolidating CA operations across multiple active instances.

Traditional AD CS clustering does not provide active-active database replication for the CA database. As a result, high-availability architectures generally rely on failover concepts rather than multiple CA nodes operating simultaneously against a replicated CA database.

Modern PKI solutions can provide more flexible high-availability architectures, including database replication and clustered deployment models. These capabilities can help maintain PKI availability even when individual components fail.

By using a modern PKI platform, companies can improve the availability and resilience of their certificate services.

Yes, certificate templates are stored in Active Directory. However, there are several limitations to consider:

Automation of template creation and modification: There is no standard built-in workflow for fully automating the creation and modification of certificate templates, which means changes often require administrative intervention.

Centralized configuration: Certificate templates are centrally available within the Active Directory environment and must be carefully designed to meet different use cases and security requirements.

Additional infrastructure: Depending on architectural and separation requirements, additional Certification Authorities and Windows Server instances may be required.

Modern PKI solutions can provide greater flexibility and automation for managing certificate policies and templates. This can reduce administrative effort, lower the risk of configuration errors, and improve operational efficiency.

Some configuration changes to a Microsoft Certification Authority require the CA service to be restarted. During this restart, the Certification Authority is temporarily unavailable.

This can be relevant in environments where the CA is frequently used or where configuration changes must be performed during normal business operations.

Modern PKI platforms can provide more flexible approaches to configuration and high availability, such as redundant components and deployment models that reduce the impact of maintenance activities.

This can help improve the availability and operational flexibility of certificate services.

Yes, Microsoft AD CS supports policy modules. However, the standard Windows policy module provides only limited flexibility for defining detailed validation rules for certain certificate request scenarios.

This can increase the risk of incomplete or incorrectly structured certificate requests if additional controls are not implemented.

A modern PKI and CLM solution such as MTG Corporate PKI & CLM provides more granular and configurable Certificate Policies that can centrally enforce requirements for certificate requests and issuance.

Yes, with the CLM Autoenrollment Connector, you can continue to use established Microsoft autoenrollment processes when migrating from Microsoft AD CS to MTG Corporate PKI. The Connector integrates MTG Corporate PKI into the existing Microsoft Active Directory environment and enables automated certificate request, renewal, and deployment through established Windows mechanisms.

The specific migration effort depends on your existing Active Directory and PKI configuration, the certificate templates in use, and your individual use cases. Preparatory changes may therefore be required. MTG supports you with the migration from Microsoft AD CS to MTG Corporate PKI and with integration into your existing Microsoft environment.

Alternatively, an existing Microsoft CA can continue to operate and be connected to MTG CLM through the Microsoft CA Certificate Provider. In this scenario, Microsoft CA remains the issuing CA while you benefit from the extended Certificate Lifecycle Management capabilities of MTG CLM.

For evaluation purposes, a locally installable test simulator can also be provided for the Autoenrollment Connector.

Active Directory Certificate Services (AD CS) primarily uses Microsoft-specific enrollment mechanisms such as RPC/DCOM and MS-WCCE. These interfaces are closely tied to Microsoft and Active Directory environments and are less suitable for many cloud-native and heterogeneous use cases.

SCEP can also be provided in Microsoft environments through NDES, but this requires additional infrastructure and configuration.

AD CS does not natively provide several interfaces commonly used in modern PKI automation scenarios, including:

• Enrollment over Secure Transport (EST)
• Automatic Certificate Management Environment (ACME), although third-party solutions are available
• Certificate Management Protocol (CMP)
• General-purpose REST- or SOAP-based certificate enrollment interfaces

Third-party solutions can be used to add some of these capabilities. MTG Corporate PKI supports modern automation interfaces such as ACME, EST, CMP, SCEP, and REST, allowing certificates to be integrated into Windows, Linux, network, IoT, cloud, and application environments.

The Network Device Enrollment Service (NDES) extends Microsoft AD CS with SCEP support, but there are several architectural and operational considerations:

Policy configuration: NDES configurations are closely tied to specific CA, certificate template, and enrollment settings, which can increase administrative complexity.

Additional infrastructure: Depending on the required separation of use cases, additional NDES or Windows Server instances may be required.

High availability: High-availability designs for NDES require additional architectural measures because enrollment state and challenge handling must be considered across instances.

Cryptographic limitations: The supported cryptographic options depend on the Windows, NDES, and certificate template configuration in use.

For organizations with broader automation, scalability, and cryptographic requirements, it may therefore be useful to evaluate modern PKI interfaces and architectures such as SCEP, EST, ACME, CMP, and REST-based automation.

Yes, Microsoft AD CS environments can use Online Responders for OCSP. As with any security-critical PKI component, however, the architecture and administrative separation of CAs, revocation services, and Active Directory must be carefully designed.

Potential risks can arise when CA, OCSP, CRL, and administrative systems share the same trust boundaries, privileged accounts, or infrastructure.

Security can be improved through measures such as:

Isolated environments: OCSP responders and revocation infrastructure can be separated from Certification Authorities and other critical systems.

Strong authentication and access control: Multi-factor authentication and role-based access control can reduce the risk of unauthorized access.

Regular security reviews: Audits and security assessments help identify and address potential weaknesses at an early stage.

By using appropriate PKI architecture and security best practices, companies can improve the resilience and security of their OCSP and revocation infrastructure.

Protecting access to Microsoft Active Directory is important when MTG PKI is integrated with an AD environment. Appropriate security measures include:

VPN (Virtual Private Network): Use encrypted network connections to protect administrative and system access.

Multi-Factor Authentication (MFA): Require additional authentication factors for privileged and administrative access.

Network Access Control (NAC): Control network access based on user, device, and security criteria.

Segmentation and microsegmentation: Separate critical systems and restrict access between network zones.

Least Privilege: Grant users and service accounts only the permissions they require for their tasks.

Monitoring and logging: Monitor security-relevant activity and integrate logs into SIEM systems where appropriate.

Hardened AD servers: Apply secure configuration standards, remove unnecessary services, and install security updates regularly.

Combining these measures can significantly improve the security of Active Directory and the overall PKI environment.

Yes, your existing Microsoft Active Directory Certificate Services (AD CS) can continue to operate while MTG CLM is integrated. The Microsoft CA remains the issuing Certification Authority, while MTG CLM adds centralized certificate management, transparency, and automation capabilities.

Depending on the HSM, Key Storage Provider, driver, and AD CS configuration, interruptions in connectivity to a network Hardware Security Module can affect the availability of the Certification Authority’s private key.

If the CA service cannot access its private key, certificate issuance and other signing operations may fail until connectivity is restored. This may also affect operations such as signing Certificate Revocation Lists.

For this reason, network HSM integrations should be designed with suitable redundancy, availability, monitoring, and recovery mechanisms to ensure reliable PKI operation.

Microsoft Cloud PKI is primarily designed for the automated provisioning of certificates to devices managed through Microsoft Intune. Certificates can be automatically issued, distributed, and renewed through SCEP profiles. Typical use cases include certificate-based authentication for Wi-Fi or VPN access.

From an enterprise-wide PKI perspective, however, the functionality is limited because the solution is primarily focused on Intune-managed endpoints. Servers, network devices, applications, or other systems outside of Intune management cannot be centrally provisioned with certificates in the same way. Companies with heterogeneous infrastructures therefore often require a broader PKI and CLM solution.

Microsoft Cloud PKI is operated entirely as a cloud service within the Microsoft environment. With a fully Microsoft-managed Cloud PKI, no local CA, NDES, or Certificate Connector components are required.

This is particularly attractive for companies that want to implement certificate provisioning entirely in the cloud and exclusively for Intune-managed endpoints. At the same time, the solution is more closely tied to the Microsoft ecosystem. Companies that also require certificates for servers, network components, applications, IoT devices, or other platforms need additional PKI and CLM capabilities.

Yes, compared with a freely configurable enterprise PKI, Microsoft Cloud PKI provides more limited options for PKI architecture and configuration. Only certain CA hierarchies and a limited number of Certification Authorities can be operated within an Intune tenant.

In addition, certain CA properties cannot be flexibly changed after the CA has been created. For companies with complex PKI structures, different certificate policies, or individual security requirements, this can limit flexibility. A dedicated enterprise PKI such as MTG Corporate PKI provides more extensive configuration options.

Microsoft Cloud PKI currently supports RSA keys with lengths of 2048, 3072, and 4096 bits, as well as the SHA-256, SHA-384, and SHA-512 hash algorithms.

This is sufficient for many traditional use cases. However, companies that want to consider additional cryptographic methods or emerging technologies such as ECC or Post-Quantum Cryptography over the long term should evaluate whether the available options meet their future requirements.

Yes, Microsoft Cloud PKI provides basic lifecycle management capabilities within the Intune environment. Certificates for Intune-managed devices can be automatically issued, distributed, renewed, and revoked.

From an enterprise-wide Certificate Lifecycle Management perspective, however, the functionality is limited because management focuses on the devices and use cases supported by Intune. MTG CLM, by contrast, is designed to centrally manage and automate certificates from different PKIs and across different systems, applications, and platforms.

The keys used by Microsoft Cloud PKI are protected within Microsoft’s cloud infrastructure. A customer-owned HSM or third-party HSM cannot be used directly as the key store for a Microsoft-managed Cloud PKI CA.

For companies that need to retain control over key material and HSM infrastructure for regulatory, organizational, or security reasons, operating their own PKI or using a Managed PKI can therefore provide greater flexibility. MTG Corporate PKI supports both On-Premises and Managed Service deployment models.

A direct 1:1 migration from Microsoft AD CS to Microsoft Cloud PKI is not intended. Microsoft Cloud PKI is primarily designed to provide certificates to Intune-managed devices and therefore does not automatically replace all existing AD CS use cases.

Companies that want to replace or modernize their existing Microsoft PKI therefore often need a solution that supports existing Windows processes as well as additional platforms and use cases. With MTG Corporate PKI and MTG CLM, an existing Microsoft PKI can either be connected and continued in operation or gradually replaced with a new PKI architecture.

Yes, Microsoft Intune can be integrated with MTG Corporate PKI & CLM through MTG SCEP. Microsoft Intune remains responsible for endpoint management and distribution of certificate profiles, while certificates are issued by MTG Corporate PKI and managed through MTG CLM.

This allows companies to continue using Microsoft Intune for endpoint management without relying on Microsoft Cloud PKI for certificate issuance. At the same time, MTG Corporate PKI can also support additional systems and use cases outside the Intune environment. This creates a centralized PKI and CLM platform for different devices, systems, and applications.

Yes, you can replace your Microsoft PKI with MTG Corporate PKI. Alternatively, you can continue operating your existing Microsoft PKI and connect it to MTG CLM. This allows you to use your existing Microsoft CA for additional use cases outside the Windows environment, such as the automated issuance of Linux server certificates via ACME.

For customers already using a Microsoft PKI based on AD CS, there are two options:

1. Connect and continue operating Microsoft PKI (AD CS): The existing Microsoft CA remains the issuing PKI and is connected to MTG CLM through the Microsoft CA Certificate Provider. Certificate processes can then be centrally managed and automated through MTG CLM.
2. Migrate Microsoft PKI (AD CS): With the MTG Auto-Enrollment Connector, Microsoft AD CS can be replaced as the issuing PKI by MTG Corporate PKI. Established Windows autoenrollment processes can continue to be used. Depending on the existing Active Directory and PKI configuration, preparatory configuration steps and, where necessary, additional adjustments may be required.

Yes, the existing Microsoft PKI can continue to operate and be connected to MTG CLM through the Microsoft CA Certificate Provider. The Microsoft CA remains the issuing PKI, while certificate processes can be centrally managed through MTG CLM.

Through MTG CLM, certificates can be requested from, issued by, and revoked through the Microsoft CA. This allows you to benefit from the centralized management and automation capabilities of MTG CLM without having to replace your existing Microsoft PKI.

MTG CLM supports the integration of different Certificate Providers. For the direct integration of an existing external private PKI, the Microsoft CA Certificate Provider is currently the primary supported option. This allows an existing Microsoft PKI (AD CS) to remain in operation while being managed through MTG CLM.

A generic direct integration of arbitrary private CAs as Certificate Providers is currently not available. If you use a different private PKI, we would be happy to work with you to evaluate the available integration options for your specific use case.

Yes, Public CAs can be connected to MTG CLM. This allows public certificates to be centrally managed and automated together with private certificates through MTG CLM.

MTG CLM currently supports direct integrations with GlobalSign, Deutsche Telekom Security through PCSP, and selected Sectigo certificates through the PSW GROUP. Existing certificates can also be imported into MTG CLM and added to the centralized certificate management environment.

The supported certificate types and available functions depend on the respective Certificate Provider. We would be happy to advise you on the Public CA integrations best suited to your specific use case.

With our Managed PKI & CLM, your enterprise environment is connected using secure access mechanisms. By default, a site-to-site VPN connection is established between your infrastructure and your dedicated Managed PKI & CLM environment.

Alternatively, a connection over the public Internet is possible. In this case, access can be restricted to defined IP addresses. All web-based access and interfaces are secured using TLS.

The most suitable connection method depends on your security requirements, network architecture, and the automation interfaces in use. We support you in selecting and setting up the appropriate connection.

ACME (Automatic Certificate Management Environment) is a standardized protocol for the automated request and renewal of certificates. It is commonly used for SSL/TLS certificates on web servers, but is also suitable for cloud-native environments such as Kubernetes or OpenShift.

With MTG ACME, MTG CLM provides an ACME interface in accordance with RFC 8555. This allows compatible ACME clients such as Certbot, win-acme, or cert-manager to automatically request and renew certificates through MTG CLM. Certificate issuance is based on the Policies defined in MTG CLM and the connected Certificate Providers.

SCEP (Simple Certificate Enrollment Protocol) is a standardized protocol for the automated request and renewal of digital certificates. It is supported in particular by network devices, Mobile Device Management systems, and other enterprise systems.

With MTG SCEP, MTG CLM provides a SCEP interface in accordance with RFC 8894. This allows compatible devices and systems to automatically obtain certificates through MTG CLM. Supported authorization methods include certificate-based and password-based approaches. MTG SCEP can also be integrated with Microsoft Intune to automatically provision Intune-managed devices with certificates from MTG PKI.

EST (Enrollment over Secure Transport) is a standardized protocol in accordance with RFC 7030 for the secure, automated request and provisioning of certificates over TLS. It is particularly suitable for IoT, mobile, and embedded systems, as well as other devices that need to automatically obtain and renew certificates.

With MTG EST, this process can be connected directly to MTG CLM. Certificate issuance is controlled through Policies that define, among other things, which CA and certificate template are used. This allows EST-capable devices to be centrally integrated into certificate management with MTG CLM.

CMP (Certificate Management Protocol) is a standardized protocol for comprehensive certificate management processes within a PKI. It supports, among other things, the request and management of X.509 certificates as well as various mechanisms for securing and authenticating communications.

With MTG CMP, MTG CLM provides a corresponding interface. Certificate requests are processed according to the Policies stored in MTG CLM, allowing the CA, certificate template, and other requirements to be centrally controlled. CMP messages can be protected using mechanisms such as shared secrets or digital signatures.

The MTG CLM REST API makes it possible to integrate certificate processes into existing applications, platforms, and automation workflows. This allows companies to interact with MTG CLM programmatically and automate certificate management processes without relying exclusively on the graphical user interface.

The API is particularly suitable for custom integrations and customer-specific workflows where standardized interfaces such as ACME, SCEP, EST, or CMP do not fully cover the respective use case. MTG provides a dedicated API reference describing the available interfaces and integration options.

The MTG ERS CLI Client makes it possible to use MTG CLM functions directly from the command line and integrate them into scripts or automated workflows. The CLI Client is available for various Windows and Linux platforms.

From the command line, users can, among other things, request certificates, check the status of certificate requests, and perform certificate scans. This makes the CLI Client particularly suitable for administrators and automated processes where a graphical user interface is not required or desired. Authentication and authorization are handled through the API clients and Policies configured in MTG CLM.

MTG IoT PKI enables the secure and scalable creation of digital device identities directly during the manufacturing process. Each device receives a unique, cryptographically secured identity and can therefore be reliably authenticated before it leaves the factory.

The solution is specifically designed for industrial series and mass production and supports high production volumes with short cycle times.

During the manufacturing process, the device generates its own unique key pair and creates a certificate request from it. The request is transferred to MTG IoT PKI and validated there. MTG IoT PKI then issues the initial device certificate, which is installed directly on the device.

This gives each device a unique cryptographic identity before it leaves the factory and enables secure authentication. Alternatively, secure key generation can also be performed using appropriately protected production clients.

Yes, certificate issuance and provisioning can be fully automated and integrated into existing manufacturing processes. MTG IoT PKI is designed for high volumes and short cycle times, making it particularly suitable for series and mass production.

Automated certificate provisioning reduces manual process steps and makes it possible to reliably equip large numbers of devices with a unique digital identity during manufacturing.

The validity period of the initial device certificates can be defined according to the security requirements and intended use of the devices. For production certificates, MTG recommends validity periods of approximately two to seven years as a best practice.

The initial certificates are intended to provide a secure device identity during production, delivery, and commissioning. During later operation, they can be replaced in a timely manner by certificates from the operational or Corporate PKI.

During operation, new certificates can be provisioned through a Device Management system and an appropriate Corporate PKI. Standardized interfaces such as EST or CMP can be used to automate certificate requests and renewals.

In combination with MTG Corporate PKI, MTG supports automated certificate renewal through EST, for example. In LwM2M-based environments, the EST mechanisms defined in RFC 7030 and RFC 9148 can be used for this purpose. Timely renewal helps prevent devices from losing secure communication capabilities because of expired certificates.

An IoT PKI creates unique and cryptographically secured device identities. This allows systems to verify whether a device is authentic and authorized to communicate.

MTG IoT PKI therefore provides a foundation for secure authentication, encrypted communication, and protection against manipulation or the substitution of unauthorized devices and components. It supports the creation of secure and traceable IoT and industrial environments.

MTG IoT PKI licensing is based on the number of certificates issued within a calendar year and therefore on the actual annual production volume.

Certificates issued in previous years that remain active do not result in cumulative licensing across multiple years. This is particularly relevant for long-lived IoT devices whose certificates may continue to require management through mechanisms such as revocation lists.

Yes, MTG IoT PKI is designed for integration into existing production and testing environments. It can be integrated into processes such as pre-personalization, firmware flashing, calibration, and serial number assignment.

This allows the digital device identity to become an integral part of the existing manufacturing process and to be automatically provisioned to the respective device.

MTG CARA is our flexibly configurable, multi-tenant PKI platform for building and operating Certification Authorities (CAs) and Registration Authorities (RAs). It provides the core functions for issuing, distributing, validating, and revoking digital certificates.

MTG CARA serves, among other things, as the PKI component of our MTG Corporate PKI and can be complemented with additional components such as MTG CLM, MTG KMS, and Hardware Security Modules depending on the use case.

CA stands for Certification Authority. It issues digital certificates and cryptographically signs them. A Registration Authority (RA) performs upstream tasks such as validating and approving certificate requests.

MTG CARA provides both CA and RA functionality, enabling customized PKI structures to be built according to specific security and organizational requirements.

Yes, MTG CARA is designed for building and operating highly secure PKI and Trust Center infrastructures and has been successfully used in Trust Center environments for many years. The platform supports complex CA hierarchies, role and rights concepts, Hardware Security Modules, different certificate formats, and various cryptographic methods.

MTG CARA can therefore also be used in regulated or certification-sensitive environments. Whether specific regulatory or trust-service requirements are met depends on the design and operation of the overall Trust Center infrastructure.

Yes, MTG CARA supports multi-tenancy. This allows large numbers of certificates to be structured and managed separately according to a domain or tenant model. For example, different organizations, business units, or customers can be represented within a shared PKI platform.

MTG CARA supports different certificate formats and application areas. These include X.509 certificates, Card Verifiable Certificates (CVCs), Attribute Certificates (ACs), and Post-Quantum Cryptography certificates.

Certificate templates can also be configured for use cases such as CAs, email, TLS, IoT, network devices, and mobile devices.

MTG CARA provides various options for integration into existing IT and application environments. Applications and target systems can be connected through REST interfaces, LDAP, and CMP, among other methods.

The REST API can be used, for example, to integrate Registration Authorities, Certificate Lifecycle Management solutions, or customer-specific front ends. This allows PKI functionality to be flexibly integrated into existing processes and applications.

Yes, MTG CARA supports the integration of Hardware Security Modules (HSMs) to securely generate, store, and use cryptographic keys. Integration can be implemented through PKCS#11 or vendor-specific interfaces.

Supported solutions include products from Utimaco, Thales, Entrust, and Securosys, as well as different HSM form factors such as LAN HSMs, smart cards, and USB HSMs.

Yes, MTG CARA is designed with crypto agility in mind. Cryptographic algorithms can therefore be used according to the applicable security requirements and replaced when necessary.

MTG CARA also already supports Post-Quantum Cryptography (PQC). This helps companies prepare their PKI for new cryptographic requirements and future migration scenarios.

MTG CARA is designed for environments with high security and compliance requirements. The platform can be operated in accordance with the requirements of BSI TR-03145 and combined with appropriately certified Hardware Security Modules.

In addition, MTG’s processes, including software development, are ISO 27001 certified. Which regulatory and compliance requirements are met in a specific deployment also depends on the respective PKI architecture and operating model.

Yes, MTG CARA is designed for operation in clustered and highly available environments. Components such as the database, web servers, and HSMs can be scaled independently depending on operational requirements.

This allows the PKI to be adapted to both increasing certificate volumes and high availability requirements.

Yes, MTG CARA provides a differentiated role and rights model. This allows responsibilities to be separated and organizational structures to be represented within the PKI.

The separation of roles and permissions supports the secure operation of PKI infrastructures with elevated security and compliance requirements, for example in accordance with BSI TR-03145.

Yes, MTG CARA can be integrated with LDAP directory services and Microsoft Active Directory. Certificates and Certificate Revocation Lists (CRLs), for example, can be exported to LDAP servers or Active Directory.

This allows existing centralized directory structures to continue to be used for distributing and providing PKI information.

MTG CARA serves as the technical foundation for a wide range of PKI scenarios and can be configured according to the requirements of the respective company or industry.

Based on MTG CARA, we implement Corporate PKIs, IoT PKIs, Trust Center PKIs, Smart Metering PKIs, TSE PKIs, and eID PKIs, among others. The platform is also suitable for custom PKI applications, such as certificate-based authentication of servers, applications, APIs, network devices, or users.