AxelSpire and Comcast: Bringing a 1.3-Billion-Certificate PKI to Enterprise IoT
Most IoT PKI platforms are scaled-up pilots. This one is a scaled-down production system.
AxelSpire is partnering with Comcast to bring xPKI — the PKI currently operating at 1.3 billion certificates across Xfinity, Sky, and Comcast's global device fleet, with daily issuance of over one million certificates and peaks of twenty million — to enterprise IoT organisations as a managed offering delivered through AxelSpire's 3AM platform.
For CISOs and VPs of Engineering deploying connected devices at scale, this changes the reference architecture question. Until now, the platforms marketed as "IoT PKI" have been commercial products built for IoT in theory and validated at customer scales measured in the low millions. xPKI was built inside one of the largest connected-device operators in the world, operates across set-top boxes, cable modems, gateways, CMTS equipment, streaming devices, CPE, and cloud services, and has been in continuous production since Comcast's Project Big Cert initiative launched in Q1 2022.
The partnership makes that production system, and the architecture behind it, commercially available.
The scale reference that matters
The four numbers that define the reference:
| Metric | Figure |
|---|---|
| Certificates under management | 1.3 billion+ |
| Daily issuance | 1M+ certificates per day, with peaks of 20M |
| Device and service categories | Set-top boxes, cable modems, gateways, routers, CMTS, CPE, streaming devices, cloud services, internal workloads |
| Continuous production since | Q1 2022 (Project Big Cert) |
Comcast operates Xfinity in the United States and Sky across the United Kingdom, Ireland, Germany, Italy, and Austria. The xPKI system issues and manages certificates for the device estate underlying Xfinity X1, Xfinity Flex, Xumo Stream Box, Xumo TV, Sky Q, Sky Glass, the XiOne streaming device, and the broader set of managed CPE, network infrastructure, and cloud services that Comcast operates across both sides of the Atlantic.
This is the environment the architecture was built for. It is the environment the architecture has survived.
What makes xPKI different from commercial IoT PKI platforms
AxelSpire's analysis of the xPKI architecture — and of the commercial IoT PKI platforms it is most often compared to — identifies five characteristics that separate a production-scale system from a commercial platform scaled up to meet it.
1. Decoupled layers that scale independently
xPKI is architected as discrete layers — CA engine, CA abstraction (Certifier), authentication and authorisation, certificate lifecycle management (xCM), revocation and status — each with its own security context and each able to scale independently. This is not how most commercial IoT PKI platforms are structured. The dominant pattern in the commercial market is a monolithic appliance or a vertically-integrated SaaS with limited horizontal decomposition. At 1.3-billion-certificate scale, with daily issuance of a million certificates and peaks twenty times that, monolithic architectures fail; decoupled ones do not.
2. A CA abstraction layer, not a single CA
The Certifier component in xPKI is a facade over multiple underlying CA engines, exposing a single interface to every client — IoT device agents, applications, build systems, internal workloads. This is the same architectural pattern AxelSpire has independently built into 3AM, and it is the pattern that makes crypto-agility, PQC migration, and multi-CA operation tractable at scale. Most commercial IoT PKI platforms tie clients to a specific CA. xPKI does not, and neither does 3AM.
3. Purpose-built constrained-device client
Comcast's libCertifier is an open-source enrollment client specifically built for constrained IoT hardware — a ~90KB binary, producing compact ~650-byte X.509v3 certificates, tested across Arm (Raspberry Pi, Android, xCam, i.MX, Ambarella, iOS), x86_64 Ubuntu, and x86_32 platforms. Most commercial IoT PKI offerings assume a device that can run a full TLS stack and a full-weight enrollment protocol. The libCertifier design assumes the device cannot, and solves for that. This is the correct assumption for the majority of the enterprise IoT estate.
4. HSM-backed CA private keys, end-to-end
xPKI's CA private keys are held in hardware security modules throughout the hierarchy. Authentication to Certifier uses enterprise identity and partner SSO via Azure. Every inbound request is security-context-enforced at the layer boundary. For enterprises operating under FIPS 140-3, Common Criteria, or sector-specific device security regimes, this is the baseline, and it is already in place in the xPKI architecture being brought to market.
5. Integration with public CA issuance where required
xPKI issues private enterprise certificates from its own CA hierarchy and also integrates with Sectigo for public-trust certificates when devices need to communicate with third-party services outside the Comcast trust anchor. This dual-mode operation — private PKI for scale and cost, public PKI for third-party interop — is the correct operational posture for enterprise IoT, and it is already built.
Why AxelSpire
Making a production PKI available as a commercial offering is a different engineering problem from operating it. A system built for a single operator's device estate has to be abstracted, instrumented, multi-tenanted, and wrapped in the operational processes that enterprise buyers will bring to it — ticketing systems, CI/CD pipelines, SIEM integration, incident response runbooks, compliance evidence generation, change management workflows.
That is the engineering problem AxelSpire solves. 3AM is a certificate lifecycle management platform and multi-PKI control plane that runs inside the customer's own AWS account, connecting issuance, renewal, and revocation events to the operational systems that actually depend on them — ticketing, CI/CD, SIEM, incident response, and compliance evidence. 3AM CertBridge is the connector from 3AM to xPKI, handling the protocol abstraction that lets the customer-side control plane speak to the xPKI back end without coupling either side to a specific CA engine. Together, they wrap xPKI in the interfaces enterprise IoT organisations need to adopt it without having to build their own operator-scale cybersecurity engineering team.
The partnership pairs a PKI that has survived production at 1.3-billion-certificate scale with the operational control plane that makes it consumable by the enterprise.
"The IoT PKI market is full of platforms that claim scale and haven't been tested at it. xPKI has been tested at it. What this partnership does is take a system that has already solved the hard problems — HSM-backed key hierarchy, CA abstraction, a constrained-device enrollment client, decoupled scaling — and make it available to the enterprises that are now trying to solve those same problems, usually from scratch, usually too late. That is a meaningful shift in what a CISO can put in their reference architecture for connected devices."
— Dan C., Founder, AxelSpire
What this means for enterprise IoT programmes
Three implications matter for decision-makers evaluating device identity strategy in 2026.
First, the "build vs. buy" equation changes. Organisations that have been evaluating internal PKI builds against commercial IoT PKI platforms now have a third option: a production-proven PKI made available through a managed control plane. For most enterprise IoT programmes, this is a better risk profile than either alternative.
Second, PQC migration becomes tractable. The CA abstraction pattern built into xPKI, and independently into 3AM, is the architectural precondition for a coordinated migration to post-quantum algorithms. Organisations adopting this offering inherit the abstraction. Organisations building on a single-CA foundation will have to retrofit it.
Third, operational maturity is no longer gated on scale. The reason most enterprise IoT programmes run PKI at a lower maturity level than their IT PKI is that the tooling and the integrations haven't existed at the device-estate scale. The xPKI + 3AM combination closes that gap. Certificate events in the device estate now flow into the same ticketing, monitoring, and incident response systems that govern the rest of the enterprise security surface.
Download the technical brief
The full technical brief covers the xPKI architecture in depth, the 3AM integration model, the deployment shape (3AM core with all enterprise integrations inside the customer's AWS account, 3AM CertBridge as the connector to xPKI), PQC readiness, and the commercial engagement model.
Download the technical brief (PDF) → (gated — corporate email required)
The brief is approximately 24 pages and is written for PKI architects, heads of device security, and enterprise security architects evaluating IoT device identity strategy.
About AxelSpire
AxelSpire is a B2B infrastructure security consultancy and certificate automation platform, founded by Dan Cvrcek, a former post-doctoral researcher at the University of Cambridge with deep, 20+ years, enterprise PKI experience in financial services environments. AxelSpire's products are marketed under their 3AM platform, a serverless certificate lifecycle management platform and multi-PKI control plane that runs inside the customer's AWS account.
About Comcast
Comcast Corporation (NASDAQ: CMCSA) is a global media and technology company. Its Connectivity & Platforms business includes Xfinity (the largest Internet provider in the United States), Comcast Business, and Sky (a leading Internet and entertainment provider across the United Kingdom, Ireland, Germany, Italy, and Austria). xPKI is Comcast Cybersecurity's internal public key infrastructure, launched as Project Big Cert in Q1 2022 to centrally manage digital certificates across Comcast's device, service, and system estate.
FAQ
Is xPKI being made available as an open-source project?
No. xPKI is Comcast's internal production PKI and will remain so. The partnership makes the architecture and capabilities commercially available to enterprise IoT customers through AxelSpire's 3AM platform as a managed offering. The libCertifier component, the constrained-device enrollment client, is separately available as open source under Comcast's existing public repository.
How does this compare to Keyfactor Command, Venafi, or DigiCert Device Trust Manager?
The commercial platforms are strong general-purpose CLM systems. They were built as products, and they are validated at enterprise scales in the low-to-mid millions of certificates. xPKI was built as operational infrastructure inside one of the largest connected-device operators in the world and is currently operating at 1.3 billion certificates, with daily issuance of over one million and peaks of twenty million. For enterprise IT PKI, the commercial platforms may be the right fit. For enterprise IoT at meaningful scale, a production-proven architecture is a different risk profile.
What about PQC readiness?
The CA abstraction layer built into xPKI's Certifier component, and into AxelSpire's 3AM, is the architectural precondition for PQC migration. Customers adopting this offering inherit a control plane that can route issuance to PQC-capable CAs as NIST-standardised algorithms (FIPS 203, 204, 205) reach production readiness across the CA vendor landscape. This is discussed in detail in the technical brief.
What regions is the offering available in?
The offering is available to enterprises operating in the United States, the United Kingdom, the European Union, and — subject to jurisdictional review — additional regions on request. Because 3AM runs inside the customer's own AWS account and the 3AM CertBridge connector links it to xPKI, most data-residency and jurisdictional constraints are resolved by the deployment model itself.
What does the engagement look like?
Enterprise IoT organisations typically start with a scoping engagement covering current device estate, existing CA topology, target operational integrations (ticketing, CI/CD, SIEM, IR), and compliance requirements. The technical brief includes an engagement outline. Scoping engagements are booked through the form linked from the brief download.
Author: Dan C., AxelSpire · Published: 18 April 2026 · Last updated: 18 April 2026