Skip to content
ECZ-IDIoT
Free Passport: Get a FREE IoT Passport

Free identity

The free IoT Passport

One IoT Passport covers one physical device, or one device identity module — a fleet is many Passports, and a firmware version is never one. This page is the whole of what the free identity establishes, the lifecycle it survives, and the four things it deliberately does not say.

The subject

One IoT Passport is one connected device

One IoT Passport is one physical device, or one device identity module, operated by your organisation. A fleet is many Passports.

What never becomes a second Passport

Firmware versions, MAC and IP addresses, and the gateways and hubs a device registers with are not separate Passports.

The shape of the identifier

ECZ-XX-XXXXXX::IOT_DEVICE-XXXXXX

A pattern, not a real record. The identifier of your organisation’s ECZ-ID Business Passport (the Parent) comes first, and the IoT Passport follows the :: separator.

Included

What the free Passport establishes

£0 · No card required · Permanent, not a trial.
  • A persistent ECZ-ID for the connected device.
  • Your organisation on the record as its operator. Its ECZ-ID Business Passport — Declared — FREE is created if you do not already have one.
  • A public Resolver record anyone can open, and the same record as machine-readable JSON.
  • A badge, a QR code and a share link.
  • Basic bindings to the public places where your connected device already appears.
  • Lifecycle and current public state, evaluated on demand.
  • Claim and recovery.
  • Basic participation in the Digital Entity Graph.
  • Essential lifecycle evidence, kept in LedgerCore.

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

Everything included free

Each free capability, in full

Every part of the free Passport that stands on its own has its own page: what it does, what it looks like, and where its claims stop.

The lifecycle it survives

What changes around a device, and what does not

A connected product is deployed, serviced, updated, handed over and retired. Its IoT Passport is issued once and stays the same throughout.

Lifecycle continuity

One device, one ECZ-ID — from the factory floor to retirement.

Everything around a connected product changes over its life: where it is installed, who services it, what software it runs, who operates it. The identity — and the record of who answers for the device — stays the same, and stays resolvable.

Same ECZ-ID at every stage

ECZ-XX-XXXXXX::IOT_DEVICE-XXXXXX

Never a raw serial number, MAC address or location.

  1. Make

    Manufacture and commission

    What changes: The device is built, its model and documentation are published, and it gets its platform credentials.

    The record: The device's ECZ-ID is issued with your organisation on the record as the accountable operator, bound to its product page and documentation.

  2. Deploy

    Deploy and install

    What changes: It joins a site, a customer estate or a cloud IoT platform, under that platform's own device identity.

    The record: Same ECZ-ID. The platform identity stays where it is; the public record says who answers for the device.

  3. Service

    Operate and service

    What changes: Support contracts, field service and repairs come and go around it.

    The record: Same ECZ-ID. Its current state and evidence stay resolvable for anyone who needs to check.

  4. Update

    Software and firmware change

    What changes: Firmware versions, components and dependencies change with every release.

    The record: Same ECZ-ID. A firmware version is never a new Passport; release and SBOM evidence attach to the enduring identity.

  5. Transfer

    Ownership or custody change

    What changes: It is sold, handed over to a customer, or moved to a new operator or service provider.

    The record: Same ECZ-ID. A change of operator is an authority change on the identity, kept as lifecycle evidence — never a new identity.

  6. Retire

    Decommission and retire

    What changes: It leaves service, is replaced or is recycled.

    The record: Same ECZ-ID. Its lifecycle state changes on the record, and the essential evidence of its life is kept.

How the pieces connect

  1. Manufacturer or operatorThe organisation that answers for the device, on the record as its Parent.
  2. IoT PassportOne free ECZ-ID per device. A fleet is many Passports.
  3. Device and product bindingsProduct pages and documentation, bound to the one identity.
  4. Software and firmware contextRelease, SBOM and provenance evidence you supply.
  5. LifecycleDeployment, service, updates, transfer and retirement — same ECZ-ID.
  6. ResolverPublic, read-only proof for people and software.
  7. Evidence · Graph · WatchLedgerCore evidence, relationship views and change awareness, when you need them.

Operating a fleet? A fleet is many Passports, all free. Device instances under active management are counted in IoT Fleet Capacity, which is separate from AEC and never consumes it.

How the two counts differ

The flow

How to get one

Six steps. ECZ-ID carries out the verification step; every other step needs something from you.

  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 connected device gets its free IoT Passport — one ECZ-ID that does not change.

  2. Bind an asset

    Name an asset your connected device is known by — for example a manufacturer product 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 boundary

What the Passport deliberately does not say

These four distinctions are the whole reason the record is worth reading. A page may shorten its own copy; it may not weaken these.

  • 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 connected device. 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 ≠ IoT verification

    A VERIFIED or ASSURED Parent verifies your organisation. It does not verify the connected device.

An ECZ-ID does not make anything safe, certified, approved or compliant, and holding one does not make you compliant with anything.

The Resolver is public, read-only proof of what is currently declared and verified, with the time it was read. A record is not a verdict, and the record itself says so and asks to be re-checked. Re-check before reliance.

Read this as carefully as the rest

An ECZ-ID does not replace any of these

An ECZ-ID IoT Device Passport is a persistent, resolver-verifiable identity for something you operate. It records who operates it, what has been declared and bound, and what the current public state is. It is not a substitute for, and must never be presented as replacing:

  • device security
  • network security
  • authentication
  • firmware security
  • safety engineering
  • device-management platforms

An ECZ-ID does not make a device safe, secure or correct, and it is not a certification, approval or test result. Your policy decides what to do with what the record says.

Get a FREE IoT Passport

Where next

Keep going with ECZ-ID IoT.

Get a FREE IoT Passport