Service & Workload specialist kit · ECZ-ID Service & Workload
ECZ-ID Service & Workload Identity & Secretless Migration Kit
Turn workload identity and secretless-migration evidence into an implementation-ready kit.
A practical product for teams replacing long-lived service secrets with workload identity while preserving an enduring service identity across pods, regions and platforms.
- Type
- Digital product
- Price
- Not restated on this site; TrustOps publishes the current price and availability
- Acquired and paid in
- TrustOps
- Operated in · proved by
- Dashboard · Resolver
The problem
Why it matters.
Services still reach cloud APIs, registries and each other with long-lived keys copied into CI variables, Kubernetes Secrets and configuration files. Every major platform now offers short-lived workload identity instead — SPIFFE and SPIRE, projected Kubernetes service-account tokens, Entra managed identities and workload identity federation, AWS IAM roles, Google Cloud workload identity federation — but migrating safely means knowing which logical service each credential belongs to, who owns it and how to roll back. That knowledge usually lives in nobody's system.
Built for
- Platform and cloud-security teams retiring long-lived service-to-cloud and service-to-service credentials.
- Service owners moving a service between clusters, regions or clouds.
- Organisations that must show a customer or auditor how service identity and access are governed.
What changes
- Clearer workload identity design
- Less secret sprawl
- Reusable migration evidence
What you receive
Concrete deliverables, not a vague trust score.
- Service/workload identity model
- Secretless migration plan
- Evidence and rollback prompts
- Implementation-ready artefacts
- Service
- The enduring logical service, and its one ECZ-ID
- Owner
- The accountable organisation and team
- Runtime identities
- The SPIFFE IDs, service accounts and cloud workload identities it runs under — kept private
- Static secrets
- Each long-lived credential, where it is used and its replacement path
- Plan
- Ordered migration steps, each with a rollback
- Exceptions
- Secrets that stay for now, and why — stated, not hidden
- Evidence
- What changed, when, and who approved it
Illustrative structure. Runtime identities and secret locations stay in your private pack; none is published on the Resolver.
How it works
A short path from need to something usable.
Define the enduring service.
Map current secrets and runtime identities.
Design the migration.
Produce the implementation and evidence pack.
How it relates to your Passport
The kit builds on the free Service & Workload Passport: one enduring identity for the logical service, the organisation on the record, bindings for its public surfaces. The migration itself happens in your provider IAM and your platform; the kit organises the plan and the evidence around the service's ECZ-ID, and reviewers re-check current public proof on the Resolver.
Use cases
- Replacing a static cloud access key in a deploy pipeline with the CI provider's OIDC identity and cloud workload identity federation.
- Moving a Kubernetes workload from a mounted key file to its cloud provider's workload identity.
- Giving each service in a SPIFFE/SPIRE mesh an accountable owner and an enduring public identity.
- Keeping one service identity unchanged while the service migrates from one cloud to another.
Tiers and price
Price and availability
Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal. This site does not restate this product's price; TrustOps publishes its current tiers, price and availability, and shows them before anything is bought.
How it is arranged
TrustOps acquires
TrustOps publishes the tiers and holds payment and entitlement whenever it is offered.
Dashboard operates
Once you hold it, it appears in your Dashboard, where you operate it.
Resolver proves
Public facts stay on the Resolver; holding it never changes what a record proves.
Privacy, security and evidence
What is collected, published and kept.
- Runtime identities, account identifiers and secret locations stay in your private pack. None is published on the Resolver.
- The pack records where each credential is used and who owns it — never a secret's value. Do not paste one into it.
- Every change is made by your team, in your own IAM and platform tooling.
- Decisive migration evidence can be kept in LedgerCore, append-only and anchored.
Boundaries
The claims stop here.
- The kit supports migration planning and evidence; it does not change provider IAM by itself.
- Secretless means replacing eligible long-lived credentials with short-lived, provider-issued workload identity. It does not remove every application secret: database passwords, third-party API keys and signing keys each need their own treatment.
- An ECZ-ID Passport is never a runtime credential. Nothing authenticates with it, and holding one grants no access to anything.
Integrations and questions
Works with what you already run.
- SPIFFE and SPIRE, and Kubernetes service accounts with projected tokens.
- Microsoft Entra managed identities and workload identity federation.
- AWS IAM roles for workloads, and Google Cloud workload identity federation.
- OIDC identities issued to CI/CD pipelines.
- Parent VERIFIED or ASSURED where a reviewer needs organisation assurance, and LedgerCore for evidence.
- Will this remove every secret from my services?
- No. It targets long-lived credentials that provider-native workload identity can replace — typically service-to-cloud and service-to-service access. Database passwords, third-party API keys and signing keys each need their own treatment, and the kit records them as exceptions rather than pretending they are gone.
- Does the kit change my IAM configuration?
- No. It produces the plan, the artefacts and the evidence; your team applies every change in your own provider IAM and platform tooling.
- Does my workload authenticate with its ECZ-ID Passport?
- No. A Passport is never a runtime credential. Workloads keep authenticating with their provider-native identity; the Passport identifies the enduring service and the organisation accountable for it.
- Is this endorsed by the cloud providers?
- No. It plans migrations to workload-identity features the providers document themselves. No partnership, endorsement or certified integration is implied.
- Where do I buy it?
- In TrustOps, which owns purchase, payment, fulfilment and entitlement.
Related
- Workflow bundleECZ-ID Machine Identity Assurance BundleCreate one assurance workflow across machine identities that live in different environments.Read more
- Regulated financeDORA ICT-vendor evidencePrepare reusable ICT-vendor evidence for customers operating under DORA.Read more
- CounterpartyDCI — Digital Counterparty InfrastructureMake a digital counterparty easier for people and machines to identify, inspect and re-check.Read more
Keep the identity free. Everything above it is optional.
Your Service & Workload Passport stays free. ECZ-ID Service & Workload Identity & Secretless Migration Kit sits above it; TrustOps shows its current state.