Skip to content
ECZ-IDService & Workload
Free Passport: Get a FREE Service & Workload Passport

ECZ-ID Service & Workload Passport™

Give services and workloads an identity that survives infrastructure change.

For platform, SRE and service teams that run production services, workloads and data pipelines — in any cloud, cluster or runtime. Infrastructure is ephemeral. Operational accountability is not. Create a durable ECZ-ID identity and proof layer across pods, clusters, regions, clouds and runtime replacements, while the provider-native workload identity underneath keeps working exactly as it does today.

Get a FREE Service & Workload PassportVerify an ECZ-IDBuild and integrate(opens in a new tab — developers.ecocitizenz.com)

£0 · No card required · Permanent, not a trial.

Everything included with one FREE Service & Workload Passport

Identity
ECZ-XX-XXXXXX::SERVICE_WORKLOAD_PASSPORT-XXXXXX
Operator
Your organisation's ECZ-ID Business Passport — Declared — FREE, created if you do not have one
Public proof
Resolver page + machine-readable JSON, open to anyone
Share
Live website badge + QR code + share link
Connections
Basic bindings + Digital Entity Graph participation
Operate
Lifecycle/current state on demand + claim/recovery + essential LedgerCore evidence
Price
£0 — no card required — permanent, not a trial

The website badge is the same live-proof pattern EcoCitizenz uses in every site footer: click it to reach current Resolver proof. DECLARED information is self-declared; re-check the live record before relying on it.

Free Service & Workload Passport

What your free Service & Workload Passport establishes.

One Service & Workload Passport is one logical service or workload your organisation operates. Pods, replicas, regions, environments and deployments of that workload are not separate Passports.

Free · Permanent · No card

The ECZ-ID launch model

Every organisation starts with one ECZ-ID Business Passport — Declared — FREE. Each of the seven family Passports — Agent, MCP, Plugin, API, IoT, SDK and Service & Workload — is free, and is taken in TrustOps once TrustOps publishes that family's door as open.

ECZ-ID Business Passport — Declared — FREEParent · created with your first family Passport

Other free starts

  • Free WatchFollow up to three ECZ-IDs on this device and see what changed, with no account and no email.Use Free Watch
  • Free Trust CheckCheck a public URL: we read its public signals and match them to the free Passport families by fixed rules. Advisory; nothing is created.Run the free check

Included, at £0

  • A persistent ECZ-ID for the service or workload.
  • Your organisation on the record as its operator. Its ECZ-ID Business Passport — Declared — FREE is created if you do not already have one. About the Parent
  • A public Resolver record anyone can open, and the same record as machine-readable JSON. About the Resolver
  • A badge, a QR code and a share link. About badges and QR
  • Basic bindings to the public places where your service or workload already appears. About bindings
  • Lifecycle and current public state, evaluated on demand. About PulseGuard
  • Claim and recovery.
  • Basic participation in the Digital Entity Graph. About the Graph
  • Essential lifecycle evidence, kept in LedgerCore. About LedgerCore
  • Publish Kit for your workload manifest or deployment annotation.
  • Manage from your ECZ-ID account.

Publishing the record is your decision. Nothing becomes public until you consent, and you can withdraw publication later.

One service or workload, one Passport

For example, your billing service keeps one Passport however many pods, replicas, regions or clusters run it.

A new pod, replica, instance, process, deployment instance, region, cluster or runtime credential is not a new Passport.

What the record never blurs

DECLARED ≠ VERIFIED
A DECLARED record states what your organisation says about itself, with the date it said it. It is not the outcome of an independent check.
Passport ≠ Binding
The Passport identifies the service or workload. A binding records a public place where it already appears. Adding a binding never creates a second identity.
Binding ≠ Authority
A binding shows that a relationship has been declared. It does not grant, prove or imply authority to act.
Parent verification ≠ Service & Workload verification
A VERIFIED or ASSURED Parent verifies your organisation. It does not verify the service or workload.
Get a FREE Service & Workload PassportRead everything included

Why, and how it works

From Passport to verified binding.

Why your service or workload needs an ECZ-ID, and exactly what happens between taking the Passport and relying on a verified binding.

  • Infrastructure is ephemeral

    Pods reschedule, clusters are rebuilt, regions fail over and clouds change. The logical service your customers depend on does not — and one Service & Workload Passport identifies that service, not the process serving it today.

  • Accountability is not

    The organisation answering for the service stays on the record through every migration. Anyone can re-check it on the Resolver — page or JSON, no account and no key.

  • Add ECZ-ID. Replace nothing.

    SPIFFE, Kubernetes service accounts, Entra, AWS IAM and Google Cloud identities keep authenticating inside your runtime. The Passport sits beside them, free, outside the execution path, and is never a runtime credential.

From the accountable organisation to public proof — across whatever runs underneath.

  1. Organisation

    The organisation accountable for the service, on the record as its operator through its ECZ-ID Business Passport — Declared — FREE. VERIFIED and ASSURED strengthen the organisation, never the service.

    Enduring · public · accountable

  2. operates

    Logical service or workload

    The enduring thing your customers depend on — the checkout service, not the pod serving it this afternoon.

    Enduring · public · accountable

  3. is identified by

    ECZ-ID Passport

    One persistent ECZ-ID for that service. It does not change when the infrastructure does.

    Enduring · public · accountable

  4. is bound to

    Cloud and runtime bindings

    Public endpoints and pages as bindings, each verified once proved with a Domain /.well-known file or DNS TXT record and then shown with when it was last verified; the clusters, regions and clouds it runs in, declared through Workload Identity Federation and never published.

    Runtime · provider-native · replaceable

  5. runs under

    Provider-native workload identities

    SPIFFE IDs, Kubernetes service accounts, Entra managed identities, AWS IAM roles, Google Cloud service accounts — still authenticating the workload, unchanged and unpublished.

    Runtime · provider-native · replaceable

  6. is proved on

    Resolver

    Public, read-only proof of the service and its operator, as a page and as JSON — re-checked before anyone relies on it.

    Enduring · public · accountable

  7. extends into

    Graph, Watch and evidence

    Relationships to the APIs it exposes and the SDKs it is built from, change awareness for those who rely on it, and LedgerCore evidence of what changed and when.

    Enduring · public · accountable

The runtime underneath can be replaced; the organisation, the service and its ECZ-ID stay. The Passport is never a runtime credential: workloads keep authenticating with their provider-native identity, a binding grants no access, and no cloud account, project, tenant or cluster identifier reaches the public record.

  1. Take the Passport

    Start in TrustOps with one sign-in. Your organisation's ECZ-ID Business Passport — Declared — FREE is reused or created, and your service or workload gets its free Service & Workload Passport — one ECZ-ID that does not change.

  2. Bind an asset

    Name an asset your service or workload is known by — for example a published service or status page. Binding never creates a second identity. Each binding records where it was learned.

  3. Choose and prepare a proof method

    Choose the live proof method that fits the asset: Domain /.well-known file or DNS TXT record. Places no live method reaches are marked Planned. Your ECZ-ID console gives you the exact value to publish for that method.

  4. Complete the proof and review

    Publish it on the asset you control, then tell ECZ-ID the proof is in place. The binding is reviewed before anything about it is published as verified.

  5. ECZ-ID verification, then the Resolver

    ECZ-ID checks the published proof and records the outcome with the time it checked. The Resolver then shows the binding with its proof method, its Last verified date and its Re-check due date — to anyone, with no account and no API key.

  6. Operate — re-check before reliance

    Keep the proof in place. A binding is verified as of a time, not indefinitely: ECZ-ID does not renew a bound binding, and after its method's freshness window a new binding is the fresh proof — re-check before reliance. Publish the ECZ-ID where people and machines already look. Strengthen only if it is useful: Parent verification, monitoring, evidence and authority are optional, and none is needed to hold a Passport.

The binding law

  1. Passport
  2. Bind asset
  3. Proof method
  4. Prepare
  5. Complete proof
  6. Review
  7. ECZ-ID verification
  8. Resolver
  9. Operate

A binding is verified as of its Last verified time, and the record shows its Freshness. ECZ-ID does not renew a bound binding: once its proof method's freshness window has passed, the result is history and a new binding is the fresh proof. Re-check before reliance.

Use cases

What Service & Workload teams use ECZ-ID for.

Real situations, each served by one product of the ECZ-ID Service & Workload domain. Every product starts from the same free Service & Workload Passport; none of them changes what it proves.

Operate this Passport

Operate your Service & Workload estate.

When one free Service & Workload Passport becomes many, these are the products TrustOps lists for the Service & Workload family. Each is optional and separate, and none changes what a Passport proves.

Universal platform

Five universal capabilities. One job each.

Scale → Monitor → Evidence → Understand relationships → Know when something changes.Five ECZ-ID capabilities sit behind every Passport family. All are optional, none changes what a Passport proves, and each is arranged through TrustOps.

One AEC: A logical service or workload you actively manage in production, with live bindings and current state. A free Passport exists and resolves whether or not you use any AEC.

IoT devices are counted separately, in IoT Fleet Capacity, and never consume AEC.

Authority & evidence, your estate plan and expert help

What a Passport may do and how a proposed action is evaluated, where receipts are kept, how the estate is operated and who can help — each optional, none of them changing what a Passport proves.

Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal.

Parent assurance

Strengthen the organisation, not the identity.

Every Service & Workload Passport hangs from your organisation's Parent, the ECZ-ID Business Passport. DECLARED is free and enough to start; VERIFIED and ASSURED strengthen confidence in who is answering for your service or workload — never the service or workload itself.

  1. DECLARED

    ECZ-ID Business Passport — Declared — FREE

    Free · created with your first Passport

    Self-declared organisation identity, published with the date it was declared. Not independently verified.

    Suits: Holding every free Passport in every family, publishing records, adding bindings and being resolved by anyone.

    Never presented as verified.

  2. VERIFIED

    ECZ-ID Business Passport — Verified

    Optional · arranged through TrustOps

    Independent verification of the organisation behind your Passports. Paying opens ECZ-ID's checks; the record shows VERIFIED only after they pass.

    Suits: Production use, and reviewers who need to know who is answering for what they approve.

    Never verifies a child Passport's subject, and never changes an ECZ-ID.

  3. ASSURED

    ECZ-ID Business Passport — Assured

    Optional · arranged through TrustOps

    The higher-assurance organisation posture. Paying opens ECZ-ID's checks; the record shows ASSURED only after they pass.

    Suits: Larger or more sensitive estates, and enterprise procurement.

    Never verifies a child Passport's subject, and never changes an ECZ-ID.

Compare the Parent tiersConfigure in TrustOps(opens in a new tab — trustops.ecocitizenz.com)

Solutions

Solve the review, procurement and supply-chain problem above the identity.

Each solution uses the same free Service & Workload identity foundation. None is a certification, a score or an approval.

Where it applies — SBOM & software-composition evidence. Connect composition, provenance and release evidence to an enduring digital-product identity. An SBOM describes composition; it is not a declaration that software is secure.

SBOM details

Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal. All solutions

Flagship digital product

ECZ-ID Service & Workload Identity & Secretless Migration Kit

Turn workload identity and secretless-migration evidence into an implementation-ready kit.

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.

What you receive

  • Service/workload identity model
  • Secretless migration plan
  • Evidence and rollback prompts
  • Implementation-ready artefacts

Boundary: 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.

See the full productConfigure in TrustOps(opens in a new tab — trustops.ecocitizenz.com)
The migration kit, for one service
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.

Relevant bundles

When the problem spans more than one kind of entity.

Bundles connect the specialist products across a real workflow. Each identity stays distinct; a bundle never merges them.

How the estate fits together

TrustOps acquires. Dashboard operates. Resolver proves.

ECZ-ID Core writes the canonical identity, state and evidence. This website explains and hands off; it never issues, edits or stores an identity.

  1. TrustOps acquires

    Owns acquisition, payment and entitlement. Every free door and every purchase happens there, and nowhere else.

    Open TrustOps(opens in a new tab — trustops.ecocitizenz.com)About TrustOps

  2. Dashboard operates

    The signed-in estate console where you manage Passports, bindings, capacity and the capabilities you hold.

    Sign in — manage from your ECZ-ID account(opens in a new tab — trustops.ecocitizenz.com)About Dashboard

  3. Resolver proves

    Public, read-only proof. Anyone can open the current record and its JSON with no account, and re-check it before relying on it.

    Verify an ECZ-IDAbout Resolver

Developer Gateway documents and integrates. Schemas, client guidance and install routes for resolving ECZ-IDs from your own code.

Open the Developer Gateway(opens in a new tab — developers.ecocitizenz.com)

Live proof

Don't take our word for it. Resolve us.

EcoCitizenz Ltd runs this site and holds its own ECZ-ID. Everything below is read from the public record, by anyone, with no account and no key — including the parts that are empty.

ECZ-ID

active

EcoCitizenz

ECZ-GB-RBS1NW

Operated by
ECOCITIZENZ LTD
Organisation tier
VERIFIED
Bound representations
None published
Public relationships
None published

The parent organisation's identity is verified. This machine is not.

Evidence available

  • Not revoked
  • Anchor recorded · not publicly retrievable
  • No live PulseGuard monitor
  • No receipts in 30 days
Resolve(opens in a new tab — resolver.ecocitizenz.org)JSON(opens in a new tab — api.ecocitizenz.com)View Graph
Last read from the public record 2026-10-14. The Resolver is the authority. Re-check before reliance.

Check it yourself

The same record answers for humans and machines. One is a page, the other is JSON with no authentication in front of it.

curl -s https://api.ecocitizenz.com/api/p/ECZ-GB-RBS1NW.json | jq .

What each field means is documented on the Developer Gateway: Resolver projection(opens in a new tab — developers.ecocitizenz.com)

What it does not prove

That this company is safe to deal with, that its software is correct, or that anyone has audited it. A record establishes who an entity is and who operates it. Everything else is your decision, and you should re-check before you rely on it.

Open the record(opens in a new tab — resolver.ecocitizenz.org)Resolve any ECZ-IDGet the same badge for your organisation

Interoperability

Works alongside what you already run.

Provider-native workload identity answers how a workload authenticates inside your runtime. The Service & Workload Passport answers which enduring service it is, who is accountable for it, what is bound to it and where anyone can re-check it. Add ECZ-ID. Replace nothing.

Native where you operate. ECZ-ID where you interoperate.Keep the identities your platforms need. Add the identity everyone else can resolve.

Related family Passports

  • SPIFFE and SPIRE

    What it does: Issue short-lived workload identities inside your infrastructure.

    What ECZ-ID adds beside it: A stable public identifier for the enduring service, rather than a rotating internal one for a running process.

  • Kubernetes service accounts

    What it does: Identify pods to the cluster and to other workloads in it.

    What ECZ-ID adds beside it: One identity for the logical workload that stays the same while pods, replicas and clusters change.

  • Microsoft Entra Agent ID and workload identities

    What it does: Govern what an agent or workload may do inside your Microsoft tenant.

    What ECZ-ID adds beside it: An identity that resolves outside the tenant, for parties with no access to it.

  • AWS IAM

    What it does: Governs what a role or workload may call inside your AWS accounts.

    What ECZ-ID adds beside it: A public identity a counterparty can read without any access to your accounts.

  • Google Cloud IAM and workload identity federation

    What it does: Govern access to your Google Cloud projects.

    What ECZ-ID adds beside it: A public identity readable outside your projects, naming the organisation that operates the subject.

  • OAuth 2.x and OpenID Connect

    What it does: Delegate authorisation and authenticate a principal for a session.

    What ECZ-ID adds beside it: A durable public record of the subject and its operator that outlives any token and needs none to read.

Platforms, standards and providers are named to show where ECZ-ID sits alongside them. Naming them implies no endorsement by, or partnership with, their owners.

ECZ-ID complements your frameworks, protocols, OAuth, cloud IAM and workload identity. It replaces none of them and stays outside the execution path.

Read the interoperability boundaries in full

Enterprise and questions

Larger estates, and the questions people ask first.

Enterprise, partners and expert help

Estate-wide capacity, procurement terms, partner arrangements and fixed-scope expert engagements are agreed directly rather than bought online. The Service & Workload Passport itself stays free at any scale.

EnterpriseTalk to us
What does a free Service & Workload Passport cost?
£0. It is permanent, not a trial, and no card is required. You pay only if you later add scale, assurance or specialist products.
What does one Service & Workload Passport identify?
One Service & Workload Passport is one logical service or workload your organisation operates. Pods, replicas, regions, environments and deployments of that workload are not separate Passports.
Who can check the record for my service or workload?
Anyone. Once you consent to publication, the Resolver serves the record as a page and as JSON, with no account and no key.
What would I ever pay for?
Capacity to operate more entities (AEC), a stronger organisation tier (Parent VERIFIED or ASSURED), monitoring, evidence, relationship intelligence, change awareness, business solutions and specialist digital products. All are optional.
Does the Service & Workload Passport verify the service or workload?
A DECLARED record states what your organisation says. A VERIFIED or ASSURED Parent verifies your organisation, not the service or workload. A binding completed through a live proof method shows control of the bound asset as of when it was last verified; it certifies nothing about the service or workload itself.

Every question, answered

Start with the identity. Everything else is optional.

£0 · No card required · Permanent, not a trial.

Get a FREE Service & Workload PassportVerify an ECZ-ID