Connect+

Ground device identity and cloud trust in X.509 certificates and a managed PKI hierarchy.

Security & PKI

Security & PKI describes how Realtek Connect+ uses a Public Key Infrastructure built on X.509 certificates to establish verifiable device identity, protect cloud communications, and support fleet-wide revocation without custom protocol work. Each device receives a unique certificate signed by the platform CA hierarchy at provisioning time. Mutual TLS authenticates every cloud connection using that certificate so the platform can verify hardware identity, enforce policy, and rotate or revoke credentials across large fleets with standard tooling.

Discuss Security & PKI All Features
Enterprise architecture diagram showing device identity, PKI trust boundaries, cloud services, and integration endpoints.

Highlights

What this service covers

  • Two-tier X.509 CA hierarchy: offline root CA and online issuing CA for device certificate issuance
  • Per-device certificates provisioned at manufacture or first activation and bound to hardware identity
  • Mutual TLS (mTLS) for every device-to-cloud connection — both sides present and verify X.509 certificates
  • Certificate lifecycle operations: issuance, renewal, rotation, and revocation with OCSP and CRL support

Capabilities

Platform building blocks

  • Operate a two-tier CA hierarchy where the root CA stays offline and the issuing CA signs device certificates on demand during provisioning workflows
  • Bind each device certificate to its serial number, MAC address, and model so the cloud can verify hardware identity without shared secrets
  • Enforce mutual TLS on MQTT and HTTPS endpoints so unauthenticated devices cannot reach platform APIs or message brokers
  • Keep hardware identity policy separate from human role assignment and product ACL availability
  • Support certificate renewal and rotation workflows triggered by expiry schedules or security events without requiring full device re-provisioning
  • Publish CRL endpoints and run an OCSP responder so relying parties can check certificate validity in real time
  • Revoke individual device certificates or batch-revoke a compromised manufacturing lot through the fleet management console

Outcomes

Why product teams use it

  • Eliminate shared-secret risks by grounding every device identity in an individual X.509 certificate
  • Satisfy enterprise and operator security reviews with standard PKI artefacts — certificate chains, CRL distribution points, OCSP endpoints
  • Keep revocation fast and scoped: a single compromised device certificate does not expose the rest of the fleet
  • Give audit teams a traceable issuance and revocation log tied to hardware manufacturing records

PKI components

Platform security building blocks

Each component is independently scoped so private cloud operators can substitute their own CA, HSM, or revocation infrastructure where required.

Component Role Operator flexibility
Root CA Offline trust anchor; signs the issuing CA certificate only. Can be customer-operated and held in an HSM outside the platform deployment boundary.
Issuing CA Online CA that signs device certificates during provisioning and renewal. Can be hosted inside the platform or replaced by a customer-operated intermediate CA that chains to the root.
Device certificate Per-device X.509 credential binding hardware identity to the platform PKI. Certificate profile (validity, key usage, SANs) is configurable per product line or deployment.
Mutual TLS enforcement Client certificate requirement on MQTT broker and HTTPS device API endpoints. Certificate validation policy and device endpoint rules are configurable per fleet or deployment tier; human roles remain account-side authorization contract scope.
OCSP responder Real-time certificate status endpoint used by relying parties to check revocation. Can be operated by the platform or delegated to a customer PKI service.
CRL distribution Periodic revocation list published for clients that cache status offline. CRL publication interval and distribution points are configurable per deployment.

CA Hierarchy

Two-tier PKI anchored in an offline root CA

The platform CA design separates long-term trust anchors from online issuance operations so the root key is never exposed to network threats.

  • The root CA is kept offline and used only to sign the intermediate issuing CA certificate and any cross-certification material. Its private key never touches a network-connected host.
  • The issuing CA operates online within the platform deployment boundary. It receives provisioning requests, validates manufacturing metadata, and signs device certificates during activation.
  • Certificate chains are short — root → issuing CA → device — so relying parties and firmware TLS stacks can validate with minimal chain processing overhead.
  • CA certificate and key material for private cloud deployments can be generated inside a customer-controlled HSM or key management service, keeping root key custody with the operator.

Device Identity

Per-device X.509 certificates bound to hardware identity

Each manufactured device receives a unique certificate that encodes its hardware identity in the Subject and SubjectAltName fields.

  • The certificate Subject carries serial number, model, and manufacturing lot. SubjectAltName extensions carry MAC address and device type URIs for policy matching.
  • Certificates are generated at one of two injection points: factory provisioning before shipment, or cloud-side issuance during first-activation onboarding for products that carry a bootstrap credential.
  • The device private key is generated on-device and never leaves the hardware. Only the certificate signing request (CSR) is transmitted to the issuing CA.
  • Certificate validity periods are set by product lifecycle expectations. Consumer devices typically receive 5–10 year certificates; industrial deployments can use shorter periods with automated renewal.

Mutual TLS

mTLS on every device-to-cloud connection

The platform enforces certificate-based mutual authentication on all MQTT broker and HTTPS API endpoints used by devices.

  • MQTT broker connections require the device to present its X.509 certificate at TLS handshake. The broker validates the certificate chain against the platform trust store and rejects connections from unrecognized or revoked certificates.
  • HTTPS device APIs apply the same client certificate requirement so every REST interaction carries a verifiable hardware identity.
  • Policy enforcement at the broker and API gateway uses the verified certificate Subject fields — serial number, model, lot — to scope which topics, endpoints, and operations the device is permitted to use.
  • Device certificates identify hardware and constrain device endpoints; they do not define human user roles or announce product ACL availability.
  • Server-side certificates on broker and API endpoints are signed by a separate service CA so devices can pin the expected server CA without conflating their own issuing CA with server identity.

Lifecycle Operations

Issuance, renewal, rotation, and revocation at fleet scale

Certificate lifecycle management is designed to work at fleet scale through scheduled operations and event-driven triggers rather than per-device manual workflows.

  • Expiry-based renewal is triggered by the device or the fleet management console before the certificate validity window closes. The device generates a fresh CSR and the issuing CA produces a replacement certificate without requiring re-provisioning.
  • Forced rotation can be triggered by a security event — compromised lot, key exposure, CA algorithm migration — and dispatched as an OTA-style campaign to affected cohorts.
  • Certificate revocation is recorded in the platform CRL and reflected at the OCSP responder within the configured propagation window. Revoked devices are disconnected at the next TLS handshake.
  • The manufacturing record and activation log are retained alongside the certificate issuance history so support teams can reconstruct the credential chain for any device in the fleet.

Next step

Evaluate Security & PKI for your product roadmap.

Share your product category, target deployment, and cloud requirements with the Realtek Connect+ team.

Talk to sales