If you work in digital trust, endpoint authentication, or identity management services, it’s likely that you’ve noticed – or are expecting – that work is getting busier. As the number of identities that your organisation has to manage balloons, and as the certificate lifecycle gets shorter, the work needed to ensure certificates and keys are properly commissioned, stored, and decommissioned is growing too.
It might even have made you wonder: is this the best way to do things?
The whole current PKI model was built for a time when networks consisted of servers and users, and relatively few of each. Modern infrastructure, by contrast, is dynamic and ephemeral. Crucially, data from the 2025 Imperva Bad Bot Report shows that in 2024, for the first, time, automated traffic surpassed human activity – a level of scale that PKI simply wasn’t built to handle.
In this blog, we’ll look at why certificates and PKI don’t suit modern architecture, and discuss approaches that provide more effective security for orchestrated systems – both now and after Q-Day.
Public key infrastructure: security for a bygone era
PKI was first developed in the 1970s and 1980s, when the internet was in its infancy and the question of online security was first considered at scale. The majority of the interactions were between human users and servers, and the number of authentications performed was a tiny fraction of what it is today.
The backbone of the authentication, of course, is formed by the certificates –the root and intermediate certificates, issued by the relevant certifying authority (CA), and the end-entity certificates that prove the identity of entities such as websites. Organisations using PKI have to manage those certificates, including:
- Getting them issued by the CA (either a public or private one)
- Generating keys to request certificates with
- Storing the keys and certificates securely
- Refreshing certificates before they expire
- Revoking them when they are compromised, or when the entity they represent ceases to exist (for instance if an employee leaves a company).
When first invented, PKI worked well. As time has passed, however, the nature of the internet and communications that take place over it have stretched the capabilities of PKI.
The rise of orchestrated systems
The single biggest change in internet traffic that puts PKI under pressure is the rise of identities that are not connected to human beings or servers. Consider the shift in software development from monolithic architecture to microservices, for instance. While a monolithic architecture involves a single-tier application that uses a single database, microservices are essentially made up of multiple smaller applications that communicate together. Each of those microservices has its own identity that requires authenticating to the rest of the application in order to keep the whole thing secure.
The rise of IoT sensors saw a similar story play out at the hardware level. There are now billions of sensors in the world that all need their own identity that can be authenticated – and crucially, many of those authentications don’t involve a server at all, but two machine identities.
The most recent chapter of this story is the rise of agentic AI. An AI agent is a non-human identity that requires authentication, but it’s an identity that frequently creates clones of itself in order to complete tasks. Those clones are ephemeral and may only last a matter of seconds before being destroyed once their task is complete – but they still require authentication to work securely.
None of this, sadly, is what PKI was designed for.
Challenges of certificate management in orchestrated systems
In this modern environment, PKI is rapidly becoming unworkable. We’ll list the challenges in a moment, but to summarise, there are three broad consequences:
- The risk of outages grows as certificates expire without anyone noticing or reacting. This can lead to service disruptions as authentications start to fail en masse.
- The risk of breach grows as certificates aren’t revoked or refreshed on time, or secrets are left in the wild for too long.
- The strain on security, developers and operations grows as they try and grapple with the problem behind the scenes.
Here are the major consequences of trying to manage certificates in decentralised and orchestrated systems:
1: The scale of management is growing
In the 1980s – and even in the 2000s – the number of identities an organisation had to manage certificates for was minimal. Nowadays, a single organisation can be in charge of thousands, perhaps hundreds of thousands, of identities – both human and non-human.
The consequences of scale:
- Certificate management is time-intensive and resource-intensive.
- Eventually, errors will start to creep in, reducing security.
2: Identities are short-lived
Non-human identities especially can be very short-lived – weeks, days, hours, or even minutes. Yet the certificate management lifecycle is still measured in months, with workflows often being manual and slow.
The consequences of short-lived identities:
- Slow lifecycle management can lead to certificates and their keys not being revoked or refreshed in a timely manner.
- As the number of unrevoked and/or unrefreshed certificates and keys grows, the risk of compromise grows too.
3: Static keys don’t work in a dynamic world
Many constrained devices such as IoT sensors, or battlefield tech, are shipped with credentials hard-coded into them. Those could include symmetric keys for encryption, device identity certificates, code signing keys, or a list of trusted root CA certificates. Conventional wisdom dictates that these devices don’t have the battery or computational power to handle secret rotation – but this turns them into liabilities.
The consequences of static credentials:
- Devices will be unable to respond to changes in the environment around them such as new CAs, meaning they may eventually be unable to communicate with some services.
- If their credentials are compromised, the device in question cannot be used any more as there is no way to change its credentials.
4: Visibility is poor
Modern networks involve a variety of different services and applications from different providers and with different requirements. Yet in many organisations, there is no central inventory of certificates – and with identities popping into and out of existence so rapidly, maintaining one would be a nightmare.
Consequences of poor certificate visibility
- Certificates expire silently, causing outages.
- Certificates aren’t revoked or refreshed when they should be, exposing you to risk.
5: Human-centric workflows
Certificate management still revolves around approval chains and workflows that are heavily manual and designed for human admins. This was fine when certificates were primarily for users and servers, but for automated pipelines that rely on certificates it’s simply not fast enough.
Consequences of human-centric workflows
- Increased risk of outages or breaches as you develop a backlog of renewals and revocations.
- Attempts to automate the process could increase the risk of things going wrong if not done right.
6: The blast radius of compromise is larger
Many orchestrated systems are set up so that once something is inside the perimeter, it is implicitly trusted. So, if one certificate or key is stolen and an attacker gains access, they are able to move laterally through the system almost at will.
On top of this, many workloads will share credentials – for instance, a Kubernetes namespace might have a single service account token. So stealing the identity of one workload will give you access to multiple. This is also true in hardware examples – often multiple IoT sensors have the same credentials baked into them in order to try and keep the management burden under control.
The consequences of a larger blast radius:
- Greater damage can be done by the attacker before the breach is noticed and plugged.
- It can be impossible to identify where the breach took place, making it difficult to protect against future breaches.
How to properly establish trust in orchestrated systems
The reason PKI is still such a major player despite its shortcomings is in part due its ubiquity, but also partly down to the lack of an alternative – at least, until we built Authentikey. In general terms, a modern and fit-for-purpose trust mechanism for orchestrated systems needs the following characteristics:
- Short-lived secrets that replace long-lived certificates and static keys.
- A disconnect between the secret and the identity; no identity should ever be synonymous with only one key or certificate.
- Automated provisioning and rotation of secrets that eliminate manual key and certificate management.
- Workflows that can manage trust at the speed of machines, rather than the speed of humans.
- Zero-trust principles that force every workload to authenticate every time, with both parties being authenticated.
- Decentralised trust anchors that allow workloads to safely authenticate even when a central authority isn’t available.
These are all features of the world’s first Continuous Trust Verification Protocol, Authentikey.
Authentikey: trust for the age of orchestration and AI
Authentikey is a novel trust mechanism that is designed for orchestrated systems, ephemeral identities, and constrained environments. Simply put, it makes it possible to give any and every identity in an orchestrated system its own unique identity and history, using lightweight and automatically rotating secrets to protect against man in the middle attacks, replay attacks, and provide perfect forward secrecy and post-compromise security.
At the core of Authentikey is a unique combination of a two-way challenge, and identical private ledgers of historic key exchanges which each party maintains. Every interaction prompts a new challenge, using new keys, which are then saved to the private ledgers once both parties correctly answer the challenge.
Authentikey isn’t just about proving that identities are genuine; it’s also about proving that both parties in an exchange have a matching history of communication – in other words, that they have always been who they say they are.
The table below shows how Authentikey overcomes each and every limitation of PKI in the age of orchestrated systems:
| PKI challenge | How Authentikey solves it |
| Growing volume of identities make management problematic. | Authentikey is managed automatically; secrets are revoked and changed at pre-configured intervals, enabling management at scale. |
| Long certificate lifecycles aren’t suited to short-lived identities. | Secrets are tied to the identity in question and refreshed with every interaction. If an identity is destroyed, so are its secrets. |
| Static keys lead to risk of breaches or obsolete devices. | Authentikey secrets automatically rotate, even in constrained environments like SIM cards, and can be updated via OTA updates. |
| Poor visibility of certificates across multiple services and environments. | Because secrets are auto-rotating, they don’t require active management. |
| Human-centric workflows can’t keep up with machine-speed authentications. | Authentikey automates the entire authentication workflow, matching the speed of M2M and agentic AI authentication requests. |
| Larger blast radius due to lateral movement once inside the perimeter. | Zero-trust principles and two-way authentication limit or eliminate lateral movement in the event of a breach. |
Learn more: what is Authentikey?
Secure modern systems with modern tools
The challenges with PKI-based trust workflows are only going to grow as the volume of orchestrated systems, autonomous agents, and M2M communications grow. The looming threat of Q-Day won’t help either; while a quantum-safe certificate signing algorithm has been created and approved by NIST, the certificates are far larger than classical certificates, and the process is more computationally intensive.
Authentikey presents one of the most compelling and fit-for-purpose alternatives out there. It enables the creators of orchestrated systems, agentic AI managers, and anyone in CI/CD environments to protect each and every interaction between every identity, human or non-human, while keeping the management burden under control.
With regular and two-way challenges and automatically rotating secrets, Authentikey shifts security from perimeter-based to identity-based, embodying the best of zero-trust principles and limiting lateral movement inside systems. Because it can run even on highly constrained devices, it’s ideal for securing small-scale hardware and systems residing on devices with limited power and battery.
Crucially, Authentikey is also compatible with a range of cryptographic keys. It can be used with ECDH keys that most organisations are using right now, and can seamlessly transition to quantum-safe keys when your architecture is ready.
To learn more about how Authentikey works and what makes it a powerful alternative to PKI for orchestrated systems, fill in the form below to download our whitepaper.