Introducing Cofide Connect: the control plane for Workload IAM

Most organisations running workloads at scale are sitting on an ever-growing credentials problem they already know they have. API keys, service account tokens, secrets embedded in config — these authenticate possession of a secret, not the identity of the workload — and in a world where non-human identities can significantly outnumber human ones, that distinction matters. When a credential can be copied, leaked in a log, or left to expire on a rotation schedule someone forgot to automate, it isn't identity. It's a shared secret with a name. We're in the midst of a Non-Human Identity (NHI) crisis.

Open standards have given us a better model. SPIFFE, OAuth, and OIDC provide the foundation for cryptographically verifiable workload identity: short-lived credentials tied to what a workload actually is, not what it knows. Services authenticate each other with certificates and tokens that rotate automatically, can't be copied out of context, and carry no long-lived shared secrets. The primitives are proven, the standards are mature, and the path away from credential sprawl is well defined.

Adopting open-standards-based workload identity means running real infrastructure. You need to configure identity authorities, establish and maintain trust relationships, and enforce policies that govern which workloads get which identities. Open standards provide the primitives, but they don't fill the gap between "getting workload identity to work" and "getting it to work reliably and auditably, without the platform team becoming a bottleneck."

That's why we've built Cofide Connect.

We believe workload identity is a core foundation for cloud security, not a capability reserved for big tech.

What operating workload identity at scale actually looks like

SPIFFE is the go-to open standard for workload identity, and SPIRE is its CNCF reference implementation. It handles node and workload attestation (proving they are who they claim to be), issuing SVIDs (SPIFFE Verifiable Identity Documents), rotating them automatically, and managing the trust bundles that let services verify each other's credentials across trust domain boundaries. It's battle-tested, with production deployments at Uber, Bloomberg, GitHub, Twilio and beyond.

The problems arise when scaling up and operationalising SPIRE in an enterprise setting. SPIRE is infrastructure, and like any infrastructure, it needs to be configured, monitored, and managed. At a small scale, with a handful of clusters, a single trust domain, and a team who all know the setup, that's manageable. At the scale where workload identity becomes most valuable, it isn't — and most organisations don't have a dedicated platform security engineering team to build the automation that makes it manageable.

SPIRE's configuration model is static. The clusters that can join a trust domain live in a file. The policies that govern which workloads get which identities live in registration entries that must be created via the SPIRE CLI or API. The trust bundles that federate separate trust domains together must be exchanged and refreshed manually or through external infrastructure and configuration.

The gap between "SPIRE running correctly" and "SPIRE running correctly across twenty clusters with three trust domains, managed by multiple teams, with a clean audit trail" is not filled by SPIRE itself. Organisations end up filling it with a mix of scripts, Helm values, and institutional knowledge held by whoever originally set things up. When that person moves on, or when the workload count grows, the cracks show.

The specific friction points we see repeatedly:

• Every SPIRE server needs a datastore. In production, SQLite isn't sufficient. You need to provision and manage a PostgreSQL or MySQL instance per SPIRE server deployment. That's more infrastructure to run, monitor, and maintain.
• Cluster onboarding is gated on the platform team. Adding a cluster to a SPIRE trust domain means editing the SPIRE server config and restarting or signalling the server. That's a privileged operation in a system most application teams don't have access to. Every new cluster becomes a ticket.
• Workload registration requires SPIRE access. Creating registration entries (the records that define which workloads get which SPIFFE IDs) requires direct access to the SPIRE server API. In most setups, that means another ticket, another round-trip through the platform team.
• Multi-trust-domain federation is entirely manual. If you run separate SPIRE deployments for different environments, business units or organisations, federating them requires exchanging trust bundles, configuring federation endpoints, and keeping everything current as certificates rotate. There's no built-in automation.
• There's no audit trail. SPIRE doesn't record who changed what configuration and when. For security-sensitive infrastructure, that's a gap.

Cofide Connect: the Workload IAM Control Plane

Cofide Connect is a Workload IAM control plane, building on open standards including SPIFFE and OpenID Connect (OIDC). It replaces static, long-lived credentials with dynamic certificates and tokens issued on demand, and provides an API-first management layer that gives teams the capability to manage workload identity resources and infrastructure without building custom automation.

Connect builds on the foundation of SPIRE, extending it to receive policy configuration at runtime. Rather than programming SPIRE directly, changes made through the Connect API propagate automatically to servers — without restarts, without a config file edit, without privileged access to server deployments.

We built Connect because we saw the same pattern repeatedly: teams sophisticated enough to adopt open-standards workload identity were still building the same operational scaffolding from scratch.

The architectural picture looks like this:

• Connect API is the control plane. It manages the authoritative configuration for trust zones, clusters, attestation policies, and federation relationships — all management operations go through it.
• Cofide SPIRE is a Connect-optimised identity runtime. It handles attestation and credential issuance, enhanced to be configured and managed dynamically by Connect rather than through static files. Connect also acts as the datastore for Cofide SPIRE, eliminating the need to provision and manage a database alongside each SPIRE server deployment.
• cofidectl CLI, Connect API, and Terraform provider are how teams interact with the system. cofidectl is the day-to-day CLI for creating and managing trust zones, clusters, policies, and federation. The API exposes the same interface for CI/CD pipelines and custom automation. The Terraform provider lets teams that manage infrastructure declaratively bring workload identity configuration into the same IaC workflow as everything else.
• SDK and sidecar integrations enable application and AI agent workloads to establish secure, verified connections — including within service meshes and across trust zones via federation.

And here's a sneak peek at what you can expect to see when you log in

Trust zones

A platform or security team creates a trust zone, defining the trust domain name, the attestation requirements, and the delegation rules: who is allowed to register clusters or workloads against it. After that, they're out of the critical path. Application teams or CI pipelines can self-serve within the boundaries the teams have established.

For instance, here's how to create a trust zone with the Connect CLI:

cofidectl trust-zone add prod \
  --trust-domain prod.example.com

Or with the Terraform provider:

resource "cofide_connect_trust_zone" "prod" {  
  name         = "prod"  
  trust_domain = "prod.example.com"
}

See the trust zone documentation for more details.

Cluster enrolment

Once a trust zone exists, registering a cluster is a single operation that any team or pipeline with the appropriate permissions can perform:

cofidectl cluster add cluster-west \
  --trust-zone prod \
  --profile kubernetes \
  --kubernetes-oidc-issuer https://<oidc-issuer-url>

Connect creates the cluster, propagates the updated cluster list to the SPIRE server, and the cluster's SPIRE agents can begin attesting immediately — without a ticket, a config file edit, or a server restart. See the cluster enrolment documentation for more details.

The platform team controls what's possible: which trust zones exist, who can register against them, what attestation profiles are required. Application teams control when it happens. This is the ownership model that scales: platform teams set constraints, application teams operate within them.

Attestation policies

Attestation policies map identities to workloads by specifying attributes of the workload that must be attested in order for an identity to be issued. In server instances, Connect programs the workload registration entries dynamically based on these policies.

Here is an example of a policy and binding that provides SVIDs to all pods in the billing namespace in the prod trust zone:

cofidectl attestation-policy add kubernetes \
  --name billing-api \
  --namespace billing
  
cofidectl attestation-policy-binding add \
  --attestation-policy billing-api \
  --trust-zone prod

Connect propagates policies to enrolled clusters automatically, programming registration entries dynamically as clusters join the trust zone. Because the cluster name can be part of the SPIFFE ID, workloads across clusters remain individually addressable even under shared policies. See the attestation policy documentation for the full policy schema.

Federation across trust zones

When workloads in different trust domains need to authenticate each other, federation is the answer. This covers cross-organisational boundaries, environments with separate governance requirements, and connections to partner infrastructure. Connect manages federation relationships centrally, handling trust bundle exchange and rotation automatically.

cofidectl federation add \
  --from prod \
  --to monitoring

This establishes one-way trust from prod to monitoring — workloads in prod can authenticate workloads in monitoring, but not vice versa. For mutual federation, add the reverse relationship too. Because Connect acts as the central control plane, it automatically negotiates the federation endpoints and handles the initial exchange of trust bundles between the two domains behind the scenes. From then on, both sides are updated automatically as trust bundles rotate. No manual exchange, no cron job watching certificate expiry, and no custom automation required. See the federation documentation for cross-organisational federation setup.

Hardware attestation

For environments where software attestation isn't sufficient — bare metal, edge, private data centres without a cloud trust provider — Connect treats TPM attestation as a first-class capability. Fleets of TPM-backed machines can be registered, attested, and decommissioned via the Connect API without building custom automation around the underlying SPIRE TPM plugin. We covered this in detail in Anchoring trust in silicon.

Open source

Cofide maintains open source tooling that makes consuming workload identity straightforward for application teams, including:

• ‍cofide-sdk-go: lets you SPIFFE-enable Go applications — see the SDK documentation to get started. ‍
• spiffe-enable is a Kubernetes admission webhook that auto-injects the necessary sidecars and configuration into Kubernetes pods, allowing applications to securely receive and use SVIDs without requiring code changes. spiffe-enable is especially useful for onboarding workloads to Connect that are not natively SPIFFE-aware. Read more in the spiffe-enable documentation.

What changes when identity infrastructure scales itself

A workload identity control plane changes more than just the operational experience. It removes identity infrastructure as a bottleneck to how fast your organisation can move.

For conventional service-to-service communication, this means mTLS across a sprawling microservices estate becomes manageable rather than aspirational. AI agents make this more urgent still: workloads that call APIs, write to databases, and act autonomously on production systems need verifiable identity just as much as any human-operated service. They'll be deployed at a pace and scale that makes ticket-based identity provisioning and secrets management untenable.

That's what Cofide's Connect is for.

Get started

If you want to explore hands-on first, the documentation covers core concepts and the open source projects show what we've built in the open.

If you're hitting the operational limits with your workload identity setup today, or evaluating workload identity and want to start on a foundation that scales, ready for enterprise deployment, get in touch. We're happy to talk through how Connect will help.

‍