PKI Platform Consolidation vs Best-of-Breed: When One Platform Wins, When Two Still Make Sense

DigiCert ONE, AppViewX AVX ONE, Keyfactor, Venafi — all claim unified enterprise and IoT PKI. The honest comparison against the two-platform pattern (enterprise CLM + specialist IoT PKI), the scenarios where each wins, and the control plane architecture that avoids forcing the choice.

The platform selection question for unified PKI splits into three choices, not two:

1. Consolidate: one platform issues enterprise and IoT certificates from a shared infrastructure.
2. Two-platform: enterprise CLM and specialist IoT PKI run independently, each optimised for its domain.
3. Unified control plane: multiple CAs (enterprise, cloud, device-specific, Matter) sit below a single control and governance layer, without forcing consolidation of the underlying issuance.

Each option has scenarios where it wins and scenarios where it fails. Vendor marketing treats consolidation as the obvious answer. The evidence from production deployments is more nuanced: consolidation wins for some organisations, two-platform wins for others, and the unified control plane is the pattern that handles the largest share of the mixed estate without forcing a premature choice.

This page is the honest comparison. It names specific platforms — DigiCert ONE, AppViewX AVX ONE, Keyfactor Command, Venafi, Sectigo Certificate Manager, Device Authority KeyScaler — and identifies where each fits.

The three architectures, in deployment terms

Consolidation: one platform for everything

One vendor provides the CA infrastructure, the enrollment protocols, the lifecycle management, and the IoT-specific capabilities. The enterprise team and device team use the same platform, the same policy framework, the same audit trail.

Examples of platforms positioning for full consolidation:

DigiCert ONE: CA operations, CLM, code signing, IoT device trust, and document signing on shared infrastructure. DigiCert operates the public trust CAs and supplies the private PKI for enterprise; IoT Trust Manager extends to device identity at scale. The platform is vendor-integrated — DigiCert is the CA and the CLM.

AppViewX AVX ONE: SaaS certificate lifecycle management with expansion into IoT identity. Following the March 2026 acquisition of Eos, AVX ONE positions as an AI-native machine identity platform spanning machines, workloads, IoT, and AI agents. CA-agnostic in design but increasingly integrated with AppViewX's own CA capabilities.

Keyfactor: Keyfactor Command for CLM, Keyfactor EJBCA as the open-source CA extended for enterprise and IoT issuance. The combination covers end-to-end PKI including high-volume device issuance. Keyfactor has been notably active in the IoT space through EJBCA deployments at scale.

Sectigo Certificate Manager: Sectigo's platform covers enterprise CLM, public trust issuance, private PKI, and IoT identity through dedicated IoT product lines. Sectigo operates as one of the largest commercial CAs by volume and brings CA infrastructure alongside the management layer.

Consolidation works when:

• Device fleet is modest (typically under 100K active devices).
• Device protocols and policies align with the consolidated platform's capabilities.
• A single team owns both enterprise and device PKI operations.
• The vendor's public trust CA is acceptable (or the platform supports private PKI at the required scale).
• Long-term vendor lock-in is acceptable as a trade for operational simplicity.

Consolidation breaks when:

• Device fleet is large enough that specialist optimisation matters (millions of devices, mass provisioning at factory scale).
• Matter-specific requirements force a separate CSA-recognised PAA/PAI chain.
• Telco 3GPP certificate requirements force specialist CMPv2 infrastructure.
• The organisation already has specialist device PKI (Device Authority, custom solutions) with substantial invested customisation.
• Multi-manufacturer, multi-region provisioning requires operational models the consolidated platform doesn't support well.

Two-platform: enterprise CLM + specialist IoT PKI

Enterprise CLM handles enterprise certificates; a specialist IoT platform handles device-specific provisioning, identity, and lifecycle. Examples:

• Venafi or Keyfactor Command for enterprise CLM + Device Authority KeyScaler for IoT device identity and lifecycle at scale.
• DigiCert CLM for enterprise + specialist Matter CA provider for Matter-specific requirements.
• AWS Certificate Manager for enterprise TLS + AWS IoT Core device identity for AWS-hosted device fleets.
• Internal enterprise PKI + contract with a specialist provisioning provider for factory identity.

Two-platform wins when:

• Device specialisation provides real operational value — Device Authority's factory integration tooling, for example, or a Matter-specific provider's CSA recognition.
• Enterprise and device operations have genuinely different cadences that would slow each other if forced onto shared infrastructure.
• Existing investment in specialist tooling is non-trivial to replace.
• Regulatory separation of enterprise and device certificate operations is desirable for audit simplicity.

Two-platform fails when:

• The two platforms have no integration and the operator has no unified view.
• Policy drift between the platforms is unmanaged — enterprise and device policies diverge without explicit coordination.
• Orphan certificates appear: device certificates attached to enterprise services, enterprise certificates attached to devices, with no inventory catching the misplacement.
• Incident response gets confused between the two platforms — who is responsible, who has the audit trail, who escalates what.

Unified control plane: multi-CA, single governance

A control plane layer sits above multiple CAs — enterprise, cloud-managed, device-specific, Matter — providing consistent policy enforcement, inventory aggregation, and audit across all of them. The control plane does not replace the CAs; it gives the operator a single management surface for policy, discovery, and oversight.

The distinction from two-platform without integration: the control plane actively reconciles policy, inventory, and audit across the CAs. Certificates issued by any CA under the control plane appear in the unified inventory with consistent metadata, are subject to consistent policy enforcement, and produce consistent audit records.

The distinction from consolidation: the control plane does not force unified issuance. A Matter DAC must be issued by a CSA-recognised PAA/PAI chain — no control plane changes that. Telco RAN certificates must come from 3GPP-compliant CMPv2 infrastructure — the control plane works alongside, not in place of. The operator retains specialist CAs where specialisation is required while gaining unified governance.

Where Axelspire's 3AM fits: 3AM implements this pattern. It is a serverless control plane that sits above multiple CAs, applies consistent policy across enrollment protocols (ACME, EST, SCEP, and CMPv2), and aggregates inventory and audit across connected CAs. It uses AWS KMS as its cryptographic engine for CA operations, enabling serverless deployment at enterprise scale. The design choice is explicit: consolidation breaks when the estate has genuinely specialist PKI requirements, so 3AM does not force it.

This architecture matches Architecture B in the unified PKI pillar — federated CAs with a shared control plane. It is the pattern that survives contact with deployments that have Matter, telco, and enterprise requirements simultaneously.

The unified control plane wins when:

• The estate genuinely has multiple specialist CA requirements that cannot be consolidated.
• Operational oversight matters more than issuance consolidation — the operator wants one view without forcing one pipeline.
• Crypto-agility across vendors is a strategic requirement — the organisation wants to move certificates between CAs without replacing the governance layer.
• Acquisitions, divestitures, or vendor changes are likely — keeping the control plane vendor-independent reduces migration risk.

The unified control plane fails when:

• Integration with underlying CAs is superficial — if the control plane only aggregates read-only data, it does not provide real policy enforcement.
• The underlying CAs lack sufficient API surface — some legacy PKI cannot be controlled programmatically and the control plane is limited to observation.
• The operational team prefers vendor-integrated simplicity over flexibility.

Platform evaluation by scenario

The correct platform choice depends on the organisation's profile. The following scenarios are representative:

Scenario A: Financial services, 200K enterprise certificates, 50K connected ATMs and branch devices

Consolidation is viable. Device fleet is modest, likely uses EST for enrollment, benefits from consistent policy with enterprise. Platforms like DigiCert ONE, Keyfactor, or Sectigo Certificate Manager handle this well with consolidated operations.

Decision criteria: existing CA relationships, regulatory requirements (FIPS, specific audit frameworks), preference for vendor-integrated vs vendor-agnostic.

Scenario B: Connected appliance manufacturer, 5M devices shipped annually, Matter-certified

Two-platform or unified control plane. Device volume demands specialist factory provisioning — either in-house at manufacturing scale or via a specialist provider (Device Authority, GlobalSign IoT Identity, Sectigo IoT). Matter DACs require CSA-recognised PAA/PAI that will be a separate chain from enterprise PKI. Enterprise CLM handles corporate certificates separately.

Decision criteria: factory integration requirements, ecosystem certification (Matter, Cyber Trust Mark), whether the organisation wants unified oversight or vendor-delegated compliance.

Scenario C: Industrial operator with 100K OT devices across multiple sites, mix of legacy and modern

Unified control plane is the operating pattern. Legacy devices require SCEP; modern devices use EST; some sites have 5G connectivity needing CMPv2. No single platform covers the protocol breadth well. The control plane provides consistent policy and inventory across whichever underlying CAs handle each protocol.

Decision criteria: protocol breadth, site heterogeneity, need for incremental modernisation without forklift.

Scenario D: Telco, 5G infrastructure, enterprise IT, consumer device offerings

Multi-vendor reality. 3GPP certificate requirements for RAN are a specialist domain (vendors with CMPv2 expertise: Nokia NetGuard, Ericsson, specialist PKI for telecom). Enterprise CLM is separate. Consumer device identity is separate again. Unified control plane aggregates but does not consolidate.

Decision criteria: 3GPP compliance, multi-vendor procurement constraints, whether "telco PKI" and "enterprise PKI" are operated by the same team (often they are not).

Scenario E: Software-first company with workload identity, modest device footprint

Consolidation, SPIFFE-centric. Workload identity via SPIFFE/SPIRE dominates. Enterprise TLS via Let's Encrypt or an enterprise CLM. Device footprint (conference room displays, IoT widgets) small enough to consolidate onto enterprise PKI with EST enrollment.

Decision criteria: investment in cloud-native tooling, minimal device operational burden, preference for open-source or commercial CLM.

Vendor positioning summary

The table is not ranked. Each platform is the correct choice for a subset of deployments and the wrong choice for others. Ranking without organisational context misleads.

The decision framework

Four questions lead to the right architecture:

1. How specialist are your device PKI requirements?

• Not specialist (under 100K devices, EST or ACME enrollment, no ecosystem certification): consolidation viable.
• Moderately specialist (Matter, 5G, industrial protocols): two-platform or unified control plane.
• Highly specialist (mass-scale manufacturing, multiple ecosystems, regulatory separation): two-platform with unified control plane almost certainly.

2. Are your enterprise and device PKI operated by the same team?

• Same team: consolidation reduces operational friction.
• Different teams, same organisation: two-platform with governance coordination or unified control plane.
• Different organisations (operator + OEM): two-platform is forced; the question is whether a control plane spans the boundary.

3. What is your sensitivity to vendor lock-in?

• Low sensitivity: consolidation with a major vendor is acceptable and offers integration benefits.
• Moderate sensitivity: CA-agnostic CLM (AppViewX, Keyfactor) or unified control plane keeps CA choice flexible.
• High sensitivity: unified control plane above multi-vendor CAs is the only pattern that preserves optionality.

4. How long is your planning horizon?

• 3-5 years: consolidation on today's best platform is acceptable.
• 5-10 years: crypto-agility and post-quantum transition matter; platforms that support algorithm rotation and CA substitution are better positioned.
• 10+ years: certificates in the field today (especially device identity) will outlast today's platforms. Unified control plane with documented migration paths is the conservative choice.

What Axelspire recommends

For most organisations, the unified control plane with multi-CA backend is the architecture that survives longest. It accommodates the specialist requirements that enterprise-only platforms fail on, it does not force premature consolidation, and it preserves the ability to substitute CAs as the vendor landscape changes.

The practical deployment pattern:

1. Identify the CAs required: enterprise issuing CA (own or commercial), Matter PAA/PAI if applicable, telco CMPv2 if applicable, any specialist device CAs.
2. Deploy a control plane that can integrate with each of those CAs via their supported protocols.
3. Express policy centrally, enforced via the control plane across all CAs.
4. Aggregate inventory and audit across all CAs into the control plane.
5. Evolve: add CAs as needs emerge, retire CAs as they are replaced, without disrupting the control plane.

3AM implements this pattern. It is not the only platform that does, but it is the platform designed from the outset for this architecture rather than retrofitting it onto a CLM foundation.

For organisations evaluating this decision, Ask Axel can walk through the scenario-specific fit. For a structured assessment, contact Axelspire — the scenario analysis benefits from looking at the actual certificate estate, not abstract requirements.

Further reading

• Unified PKI for enterprise and IoT
• PKI enrollment protocols for enterprise and IoT
• Certificate lifetime policy across enterprise and IoT
• Mixed key storage in unified PKI
• Governance across enterprise and device PKI
• IoT vendor lock-in and device identity