Trust infrastructure for AI and satellites shifts into focus

At a glance

What this is: WISeKey frames its corporate restructuring and subsidiary listing as part of a broader push to build trusted infrastructure for AI, IoT and satellite connectivity.

Why it matters: This matters because identity, cryptography and device trust are becoming control-plane issues for distributed systems, including connected devices and autonomous services.

Context

The governance gap here is not about connectivity alone, but about how trust is established when devices, services and AI systems interact across mixed terrestrial and space environments. In that setting, authentication, provenance and transaction integrity become design requirements rather than after-the-fact controls.

WISeKey is positioning its portfolio around a familiar but still unresolved problem: how to make machine-to-machine ecosystems verifiable when the participants, links and decision points are distributed. That is a broader identity and trust architecture question, not just a product story.

Key questions

Q: How should organisations govern machine identities across multiple regions?

A: Use a global identity strategy for trust, lifecycle, and automation standards, then apply local governance for evidence, accountability, and revocation requirements. The practical test is whether each region can prove control during an outage, audit, or incident review. If a policy cannot produce local evidence, it is not operationally complete.

Q: Why do autonomous systems need stronger identity controls than traditional connected devices?

A: Autonomous systems create risk because they can initiate actions without a human approving each step. That means identity and authorization must be bound to the action itself, not just to network access. If a system can decide, transmit or transact, practitioners need assurance over who it is, what it may do and how that permission is revoked.

Q: What happens when remote devices cannot be continuously verified?

A: Gaps in continuous verification force organisations to rely on cached trust, delayed validation or implicit acceptance of device behaviour. That can be workable for short periods, but it becomes risky when the endpoint can still initiate transactions or move sensitive data while disconnected. The control objective is to keep authentication and revocation decisions usable under degraded connectivity.

Q: What is the difference between PKI trust and hardware-rooted trust?

A: PKI trust relies on cryptographic certificates to vouch for identity, while hardware-rooted trust anchors that identity in a secure element, chip or similar protected foundation. In practice, they work together: PKI distributes and validates trust, while hardware rooting makes key extraction and identity cloning harder. Organisations should not treat them as substitutes.

Technical breakdown

How hardware-rooted trust supports device identity

Hardware-rooted trust starts with a device asserting an identity anchored in silicon, keys or secure elements rather than in software alone. That matters because software-only identities are easier to clone, export or abuse when systems scale across factories, fleets and remote links. In this model, the device proves it is genuine, then uses cryptographic credentials to authenticate services and sign transactions. The key governance issue is lifecycle control: provisioning, binding, rotation and revocation all have to remain consistent across device classes and deployment environments. See the Identity Visibility and Intelligence Platforms (IVIP) Guide.

Practical implication: Treat device identity as a managed lifecycle, not a one-time enrollment event.

Why post-quantum cryptography matters for long-lived machine trust

Post-quantum cryptography is intended to reduce the risk that today’s protected traffic, keys or signatures become readable or forgeable once cryptographically relevant quantum systems mature. For infrastructure that may remain in service for years, that is especially important because the trust boundary extends beyond immediate confidentiality to future authenticity and non-repudiation. The architectural challenge is migration: organisations rarely replace every device, certificate path or signing workflow at once, so hybrid trust models are likely to persist during transition.

Practical implication: Inventory which machine identities and signed workflows will still need protection over a multi-year horizon.

How trusted satellite connectivity changes the identity problem

Satellite connectivity extends the trust problem beyond local networks, which means identity controls have to survive intermittent links, remote sites and constrained endpoints. In that environment, authentication cannot rely on continuous central verification alone. Devices need credentials that remain verifiable when connectivity is delayed, degraded or routed through multiple intermediaries. That pushes architects toward stronger onboard identity, tighter certificate governance and explicit validation of data origin before action is taken. The issue is not just transport security, but whether remote devices can still be trusted to act on what they receive. See the Space and Satellite Cybersecurity Guide.

Practical implication: Design remote-device authentication and signing so they still work when connectivity is intermittent or indirect.

NHI Mgmt Group analysis

Trusted infrastructure is becoming an identity governance problem, not just a connectivity problem. Once devices, services and AI systems can initiate actions independently, the question is no longer whether data moves securely, but whether the actor on the other end can be authenticated and authorized consistently. That moves machine identity from a supporting control to the foundation of operational trust. Practitioners should treat distributed systems as identity systems first.

Machine trust sprawl: the more environments a device must cross, the more places identity can break. A device that spans hardware, cloud, satellite and application layers needs credentials, signing logic and provenance checks that remain coherent across all of them. If those controls are implemented independently, governance becomes fragmented and trust assumptions drift. Practitioners should map every trust boundary a machine crosses before the first deployment.

Post-quantum migration will expose where machine identity was never lifecycle-managed. Organisations that have treated certificates, keys and signing chains as static infrastructure will find that hybrid cryptographic eras demand inventory, rotation and revocation discipline. The real risk is not just future cryptanalysis, but unmanaged coexistence between legacy and quantum-resistant trust paths. Practitioners should identify where long-lived devices will outlast today’s cryptographic assumptions.

Digital identity and PKI remain central because autonomous systems cannot be governed by telemetry alone. A system that can trade, transmit or decide on its own must prove who or what it is before policy can be applied. That makes identity assurance, certificate governance and transaction signing inseparable from operational resilience. Practitioners should align identity controls to the autonomy of the system, not the convenience of the architecture.

What this signals

Distributed trust will become a governance discipline before it becomes a platform feature. As more systems operate across terrestrial and space links, identity assurance has to survive inconsistent connectivity, device heterogeneity and delegated decision-making. The practical shift is toward control models that can verify the actor before action, not after the event.

Machine identity and cryptographic lifecycle management will converge. Long-lived devices, signing workflows and autonomous services will increasingly depend on the same underlying control plane: credential issuance, revocation and provenance. Organisations that do not unify those controls will end up with trust islands that are difficult to audit or retire.

Identity assurance is now a prerequisite for autonomous transaction design. If a connected system can exchange value or trigger operations on its own, the policy question changes from access management to trust validation. Practitioners should assume that future programme reviews will ask whether a machine identity can prove origin, integrity and authority at the point of action.

For practitioners

• Map machine identity across every trust boundary Document where devices, services and AI systems authenticate today, including satellite links, cloud services and partner environments, then identify where trust is inferred rather than verified.
• Inventory long-lived credentials and signing chains Find certificates, keys and device credentials that may need to survive a multi-year cryptographic transition, then classify them by business criticality and replacement difficulty.
• Separate trust domains for remote and local operations Avoid assuming that the same control model works across terrestrial and space-connected systems, especially where latency, outage or intermittent connectivity changes validation timing.
• Define revocation paths before deployment at scale Ensure you can revoke device identity, keys and signing authority quickly when hardware is lost, compromised or retired, even when the endpoint is remote or intermittently reachable.

Key takeaways

• The article frames trust, identity and cryptography as the foundations of distributed AI and satellite systems, not as secondary security features.
• Its strongest governance implication is that machine identity now spans hardware, connectivity and transaction layers, which makes lifecycle control essential.
• Practitioners should prepare for long-lived hybrid trust models where revocation, provenance and authentication must work across remote and intermittent environments.

Related NHI Mgmt Group resources: Identity Visibility and Intelligence Platforms (IVIP) Guide · Space and Satellite Cybersecurity Guide · AI Governance Guide

Key terms

• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Hardware Root Of Trust: A hardware root of trust is a device-level trust anchor, often backed by a TPM or similar mechanism, that proves a system is what it claims to be. It helps infrastructure enroll without relying on static bootstrap secrets and gives identity systems a more durable basis for issuance and attestation.
• Post-Quantum Cryptography: Cryptographic algorithms designed to remain secure against attacks from sufficiently powerful quantum computers. In practice, PQC is a migration problem as much as an algorithm problem because organisations must replace trust anchors, certificates, and secrets without breaking identity-dependent systems.
• Trusted Transaction Boundary: The trusted transaction boundary is the line between a valid signature and the identity, workflow, and storage controls that make that signature defensible. It helps practitioners see that the security problem is not the signature alone, but the delegated access and audit trail around it.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It is designed for practitioners who need to align identity control with real operational risk across modern infrastructure.