The last time your organization had a serious outage, there is a good chance a human did not cause it directly. Instead, a certificate quietly expired on a critical API endpoint, a long-lived token was reused in a way no one expected, or a bot account behaved “correctly” according to its configuration while everything around it shifted. At most enterprises, machine identities have become the real arteries of the business, but they are still treated like plumbing work orders instead of a strategic security surface. That gap is where the real riot is already brewing.
In this Wednesday “Headline” feature from Bare Metal Cyber Magazine, we look at what happens when certificates, tokens, keys, and bots multiply faster than anyone can meaningfully own them. Cloud-native architectures, software-as-a-service sprawl, automation platforms, and early AI agents have pushed non-human identities to vastly outnumber users, yet most governance, monitoring, and incident thinking still orbits around people. Public Key Infrastructure (PKI), token services, and “service accounts” are scattered across teams and platforms, each with its own assumptions, lifetimes, and failure modes.
For security and technology leaders, this is no longer a hygiene issue buried in infrastructure backlogs. Machine identity sprawl is now a direct driver of operational risk, detection blind spots, and attacker leverage. Over the next 12–24 months, the organizations that win will be the ones that treat machine identity as a platform: discovering it, standardizing it, and giving developers safe defaults instead of ad hoc secrets and forever-tokens. The ones that do not will keep discovering, at awkward moments, just how much of their “zero trust” depends on a handful of brittle, poorly understood trust anchors.
This article maps that trust fabric, shows how it quietly fails, and then walks through what ownership, lifecycle control, and platform thinking look like when certificates, tokens, and bots are no longer side characters but the main cast.
The Quiet Majority of Your Identities
If you inventory every user account in your environment today, you will probably feel like you are looking at a large, complex system. Add in contractors, partners, and privileged accounts, and it seems even bigger. But that human-centric view is already outdated. In most mid-sized and large organizations, machine identities outnumber human identities by an order of magnitude: certificates on internal services, API keys between platforms, workload identities in Kubernetes clusters, tokens passed between microservices, and bots doing unattended work on behalf of teams. They are the silent majority of your identity surface, and they drive most of your high-volume, high-criticality traffic.
The reason is simple: everything has become an integration point. Each new SaaS product, each “temporary” script, each automation runbook, and each cloud deployment adds at least one new non-human identity, often several. A cloud-native SaaS company might have a handful of engineers and thousands of short-lived workload identities rotating behind a gateway. A regulated bank might have comparatively stable human headcount but constantly growing fleets of service accounts, hardware security module (HSM) keys, and internal certificates that tie channels together. Yet the dashboards that leaders review still tend to show multi-factor adoption for people, not the blast radius of a single compromised token.
This mismatch is not just about numbers, it is about criticality. Human users may be the most visible security concern, but machine identities often have higher baseline privileges and more predictable access. The token that lets a CI/CD pipeline deploy to production, the certificate that terminates TLS in front of a payment API, or the bot account that reconciles financial data across systems can all operate at a level a normal employee never will. When those identities are opaque, long-lived, or scattered across teams with no shared lifecycle model, leaders lose the ability to reason about how trust really flows through their environment. Machine identities become background noise, until one fails or is abused and the entire business feels it.
Certificates, Tokens, and the New Trust Fabric
When you look at the environment from a machine’s point of view, the trust story is surprisingly simple: “I present a credential, something verifies it, and then I get to do things.” The complexity comes from how many credential types and trust engines are in play. Internal and external certificates front everything from user-facing portals to east–west service meshes. OAuth and OpenID Connect tokens bridge identity providers and applications. API keys and shared secrets still show up wherever developers needed “just a quick integration.” Workload identities from cloud providers promise to get rid of static keys, while robotic process automation bots log in like humans but behave like scripts. Each of these is a piece of your trust fabric, but they often grew up in parallel, not as a deliberate whole.
Underneath the names and protocols, the pattern is consistent: something asserts who or what the caller is, and something else decides what that caller can do. A certificate chain rooted in your internal Certificate Authority (CA) lets one microservice trust another. A token issued by an identity provider carries claims or scopes that an API trusts. A workload identity from a cloud provider uses metadata and attestation instead of a static key. From a leader’s lens, the important question is not “which protocol are we using?” but “which authority decides this caller is real, where is that decision logged, and how do we revoke it when we need to?”
What makes this fabric fragile is that each trust domain has its own tooling, assumptions, and operational “owners.” The PKI team worries about certificate issuance but may not control how private keys are stored. The identity team manages single sign-on but only touches the human side of OAuth, not the service-to-service flows. Platform engineering might own Kubernetes workload identities, while SaaS admins hand out long-lived API keys by request. Without a shared model of how certificates, tokens, and keys fit together, leaders end up with islands of well-run trust and large, murky in-between spaces where bots, scripts, and integrations live indefinitely. That is where the riot has room to start.
How Machine Identity Fails (Without Exploding Yet)
Most organizations already have a long list of machine identity failures, even if they are not labeled that way. There was the “mysterious” outage when a TLS certificate expired on a load balancer that nobody realized was still critical. There was the integration that silently stopped posting alerts because its API key was rotated in one system and forgotten in another. There was the pipeline that kept deploying with a token everyone assumed was short-lived but turned out to be effectively permanent. These incidents are often triaged as one-off misconfigurations or change-management misses, not symptoms of a deeper lifecycle problem. The system keeps working just enough that leaders do not see the pattern.
The more subtle failures are about accumulated exposure. Long-lived tokens with broad scopes end up reused across pipelines, cron jobs, and internal tools because they “just work.” Service accounts created for a project that was sunset three years ago still hold database roles because nobody wants to risk breaking anything. Bots are granted access to whole domains of data because no one has time to design fine-grained scopes. Vaults exist, but developers cache credentials locally or hardcode them in test harnesses to avoid friction. On paper, there is a secrets management program and a PKI. In reality, there is a shadow ecosystem of credentials that are invisible to inventory and monitoring.
Attackers love this landscape because it gives them durable, low-noise access. A phished user credential might trigger an alert, but an API key exfiltrated from a misconfigured repository or a token stolen from a build agent log can operate quietly for months. Even without a breach, these same weaknesses drive operational fragility. A single forgotten certificate can take out an internal control plane. A mis-scoped bot can delete or corrupt data at machine speed. These events are rare enough, spread out enough, and labeled as “root cause: human error” often enough that leaders accept them as normal background risk. The riot is not a single explosion; it is the steady erosion of trust and reliability every time a certificate, token, or bot behaves in ways nobody anticipated.
From Snowdrift to System: Owning the Lifecycle
Turning machine identity from chaos into a system starts with admitting that this is a lifecycle problem, not a tooling problem. Certificates, keys, and tokens are born, they live, and they should die on purpose. For most organizations today, only the middle of that lifecycle is visible: something exists and it seems to work. Issuance is scattered across homegrown scripts, cloud consoles, SaaS admin panels, and ad hoc CAs. Decommissioning is almost nonexistent, handled informally when someone notices “we do not need that anymore” and remembers how to remove it. Leaders who want to change this have to define lifecycle stages explicitly and treat them as design constraints for platforms and teams, not as after-the-fact controls.
A useful mental model is to ask, at each stage, “what is automated, what is enforced, and what is observed?” Discovery means you can reliably answer “what certificates, keys, tokens, and service accounts exist, where, and for what?” Issuance means those artifacts come from known authorities with policies baked in: key length, algorithms, lifetimes, scopes. Rotation means time-bound credentials are refreshed by machines, not humans with calendar reminders and tickets. Revocation and decommissioning mean you have a reliable kill switch that propagates through the ecosystem and clears out dead identities. When this lifecycle intersects with CI/CD, infrastructure as code, and platform engineering, it stops being governance by spreadsheet and turns into part of how you ship.
In practice, this shift looks like consolidation and opinionated defaults. Instead of every team running its own CA or creating its own API keys in vendor portals, you stand up a small number of issuing authorities and secret stores, integrated directly into build and deployment workflows. Developers request identities through code or pipelines, not email. Short-lived credentials become the norm, so the cost of compromise drops and the cleanup burden shrinks. Logs from issuance, use, and revocation feed a central view that risk teams and incident responders can actually work with. None of this removes the need for local expertise, but it creates a shared system that outlives any one engineer, migration, or tooling trend. That is what “owning the lifecycle” looks like at leadership level.
Platform, Not Project: Who Owns the Bots?
Once you see machine identities as a lifecycle, the next hard question is organizational: who actually owns this thing? Many enterprises have treated PKI, token services, and bot governance as a string of projects: “fix certificate outages this quarter,” “set up a new secrets manager,” “roll out the RPA platform.” Those efforts can deliver short-term wins, but they rarely survive intact through acquisitions, cloud migrations, or leadership changes. Machine identity needs to be run as a platform, with clear product ownership, a roadmap, and service guarantees, not as a series of tickets and tactical remediations. That shift in thinking is often more important than any particular technology choice.
A platform mindset means someone is accountable for the end-to-end experience of non-human identities. They define standard patterns for service-to-service auth, publish APIs and libraries for obtaining short-lived credentials, and maintain reference architectures that show teams how to integrate safely. They also own the reliability story: service-level objectives for issuance, revocation, and key management; dashboards that surface unhealthy dependencies; and runbooks for incident response when something in the trust fabric breaks. In many organizations, this responsibility naturally sits at the intersection of security, identity, and platform engineering. The exact org chart matters less than having a named team whose mandate is to make machine identity boring and dependable.
Bots complicate the picture because they blur lines between human and machine. RPA bots log in like users but operate at machine speed across critical systems. Internal AI assistants may act on behalf of employees, invoking APIs, reading documents, and making changes in systems of record. If each of these emerges from a different project with its own identity assumptions, you end up with a zoo of “special” accounts that bypass the very platform meant to control risk. A mature approach treats bots as first-class citizens of the machine identity platform: they obtain credentials through the same lifecycle, are limited by the same scopes and policies, and are monitored and decommissioned like any other workload. Leadership’s job is to insist that new automation does not get a free pass, and to fund the platform capacity needed so the safe path is also the easiest path.
Preparing for the Next Riot
The environment you are stabilizing today is already being stressed by the next wave of change. AI agents that call APIs on their own, software supply chain signing requirements, hardware-backed attestation, and dense edge deployments are all pushing more trust decisions into code. Each of these trends multiplies machine identities and raises the stakes of getting them wrong. An AI assistant that can create tickets is one thing; an AI agent that can modify infrastructure or change customer records is another. The credentials those agents use, the authorities that vouch for them, and the logs that record their actions will decide whether they become trusted colleagues or new attack surfaces.
Software supply chain security is applying similar pressure from a different direction. Requirements to sign artifacts, attest builds, and verify provenance mean that identities now matter at every step from source code commit to production deployment. If signing keys are scattered, poorly protected, or long-lived, your “supply chain security” story becomes theater. The same is true at the edge: fleets of IoT devices, branch appliances, and industrial equipment depend on certificates and keys that often cannot be touched easily once deployed. The difference between a manageable fleet and a long-term liability is whether you designed a lifecycle and authority model up front or accepted whatever defaults vendors shipped.
Leaders do not need to predict every technology trend to prepare for this next riot. They need to make a few durable choices now that will scale: consolidate and harden a small set of root authorities; default to short-lived, purpose-bound credentials; require that new platforms integrate with the machine identity lifecycle instead of creating their own islands; and demand observability for how non-human identities are issued, used, and revoked. These moves give you more room to maneuver when the next wave of AI agents, regulations, or platform patterns arrives. If machine identity is already a coherent platform, not a collection of exceptions, you can plug in new trust mechanisms without losing sight of who your machines really are and what they are allowed to do.
Where Leaders Go From Here
At its heart, this topic is about taking back control of the trust fabric your business already depends on. Machine identities are no longer peripheral plumbing; they are the primary way your systems recognize one another, move data, and execute decisions at scale. Certificates, tokens, keys, and bots have multiplied into a landscape that humans can no longer manage by memory, ticket, or tribal knowledge. When leaders treat that reality as background noise, they end up accepting outages, blind spots, and quiet abuse as inevitable side effects of modern infrastructure instead of symptoms of a system they could redesign.
Stepping back to the system-first view, the picture is clear. You have a growing population of non-human identities, a patchwork of issuing authorities and vaults, and a set of fragile lifecycles that are only partially automated. You also have a choice: continue to run machine identity as scattered projects and emergency fixes, or recognize it as a platform that deserves ownership, funding, and service-level expectations. Owning the lifecycle, consolidating authorities, giving developers safe defaults, and putting bots and AI agents under the same umbrella are less about perfection and more about direction. Each move makes your trust fabric more observable, more revocable, and more resilient to both mistakes and attacks.
When a leadership team truly internalizes this, several things change. Conversations about outages and incidents start to ask which identity failed, not just which change window it fell into. Funding discussions shift from one-off PKI upgrades to durable machine identity platforms. New automation and AI projects are required to plug into the lifecycle, not bypass it. If you want a concrete next step, ask your teams two questions: “Can we map our non-human identities end-to-end?” and “Who is accountable for making that map simpler a year from now?” The answers will tell you how close you are to calming the machine identity riot—or how much work remains.