Introducing ObjectID Digital Twin: Standardized Architecture, Blockchain-Verifiable Evidence and Customer-Controlled Infrastructure

A Digital Twin platform architecturally aligned with ISO/IEC 30188:2026, with hosted and self-hosted integration options

ObjectID Digital Twin introduces a different approach to industrial Digital Twins.

It combines four fundamental capabilities:

• architectural alignment with the ISO/IEC 30188:2026 Digital Twin reference architecture;
• blockchain anchoring of identity, lifecycle events and digital evidence;
• hosted or privately operated MQTT and Integration Server options;
• customer-controlled storage in self-hosted deployments.

This combination addresses a central limitation of many existing Digital Twin platforms.

Organizations should not have to choose between interoperability and privacy, between verifiable evidence and industrial performance, or between using a Digital Twin platform and maintaining control of their infrastructure.

ObjectID provides a hosted Integration Server for organizations that want to start immediately.

Organizations requiring greater infrastructure control can instead operate their own MQTT broker, Integration Server and storage environment.

In both cases, ObjectID provides the persistent identity, governance and verification layer that connects these components into a trusted Digital Twin system.

Hosted or self-hosted integration

ObjectID Digital Twin supports two operating models.

With the hosted service, each customer receives:

• an on-chain SubscriptionAccount;
• dedicated tenant API credentials;
• dedicated MQTT credentials;
• MQTT access-control rules limited to the customer’s Twins;
• an operation allowance defined by the selected subscription;
• access to the public ObjectID Integration Server at dtis.objectid.io.

Twin creation, state publication, dataset registration, events and commands consume the monthly operation allowance of the customer’s subscription.

IOTA transaction gas is managed separately. ObjectID sponsors gas through the ObjectID Gas Station for operations targeting the controlled Digital Twin package.

On testnet, users can activate a free Base subscription directly from the Webview. The testnet subscription renews automatically after expiry while retaining the same account and Digital Twins.

The hosted Integration Server currently provides a standard 30-day retention period for managed off-chain data.

Organizations requiring full infrastructure control can instead deploy their own ObjectID Integration Server and connect it to their own MQTT broker and storage.

The Digital Twin identity and governance remain on-chain, independently of which Integration Server is used.

Built around the ISO/IEC 30188:2026 reference architecture

ISO/IEC 30188:2026 specifies a general reference architecture for Digital Twin systems through a set of architectural views.

This is an important development for the Digital Twin market.

Until now, the term “Digital Twin” has often been applied to very different solutions: dashboards, simulation models, IoT databases, 3D representations and asset-management applications.

ISO/IEC 30188:2026 introduces a common architectural foundation for describing how the components of a Digital Twin system relate to each other.

ObjectID Digital Twin has been designed around this separation of responsibilities.

Its architecture distinguishes between:

• the physical or logical asset;
• the Digital Twin representation;
• devices and data sources;
• communication interfaces;
• operational services;
• identity and governance;
• external storage;
• users and stakeholders;
• lifecycle and verification services.

This is not only a documentation exercise. It directly influences how the platform has been implemented.

Instead of creating a monolithic application that owns the device connection, database, identity and user interface, ObjectID separates these responsibilities into interoperable components.

The resulting architecture allows an organization to replace or independently operate individual components without losing the persistent identity and history of the Digital Twin.

ObjectID’s current implementation is architecturally aligned with ISO/IEC 30188:2026.

This statement describes the design approach and should not be interpreted as a claim of formal ISO certification.

Blockchain anchoring, not indiscriminate blockchain data storage

ObjectID Digital Twin uses blockchain where blockchain provides genuine value:

• establishing persistent identity;
• representing authority and governance;
• ordering lifecycle events;
• recording revision transitions;
• anchoring integrity evidence;
• providing independently verifiable references.

ObjectID does not require high-frequency industrial telemetry to be written on-chain.

High-frequency machine data can be large, sensitive and commercially confidential. Writing every temperature or vibration measurement to a public distributed ledger would be inefficient and would conflict with many privacy and data-governance requirements.

ObjectID therefore separates operational data from verifiable proof.

Operational data remains off-chain

Telemetry, datasets, machine models, documents and media can remain in storage selected by the Integration Server operator.

In the hosted service, this storage is managed by ObjectID.

In a self-hosted deployment, it can remain entirely under the organization’s control.

Selected states and verifiable evidence can be anchored on-chain

Periodic telemetry is normally aggregated into off-chain datasets.

Selected state snapshots, lifecycle events, dataset references and integrity evidence may be registered on-chain when independent verification is required.

Depending on the resource type, ObjectID can register:

• the Digital Twin identifier;
• the event type;
• the Twin revision before and after the event;
• the actor DID;
• a resource, payload or storage reference;
• a SHA-256 content hash;
• schema and provenance information;
• the relevant period or version;
• the blockchain transaction timestamp.

The hash acts as a unique fingerprint of the original content.

A verifier can later retrieve the stored file, calculate its hash again and compare it with the hash registered through ObjectID.

If even one byte has changed, the calculated hash will no longer match.

This model can support verifiable references for:

• maintenance reports;
• inspection results;
• calibration certificates;
• technical drawings;
• machine configurations;
• firmware references;
• quality-control evidence;
• datasets and selected operational states;
• ownership and stewardship changes;
• command evidence;
• decommissioning records.

The blockchain does not need to contain the underlying private document or complete operational dataset.

It preserves the identity, provenance and integrity references required to verify the resource.

Persistent identity and verifiable governance

Every ObjectID Digital Twin receives a persistent OIDTwin object identifier.

Unlike a conventional database ID, this identity is not meaningful only inside one application.

It is connected to an on-chain governance model implemented through IOTA and Move smart contracts.

The core Twin record tracks:

• Creator;
• Owner;
• Steward.

Optional role grants can represent additional stakeholders, including:

• Manufacturer;
• Operator;
• Maintainer;
• Data Provider;
• Model Provider;
• Service Provider;
• Certifier;
• Auditor.

These roles support stakeholder representation and Integration Server policy evaluation.

In the current implementation, Owner and Steward remain the primary authorities for protected governance operations such as modifying the Twin, changing its visibility or publishing its public location.

The persistent identity can survive changes to:

• the Webview;
• the MQTT broker;
• the Integration Server;
• the storage provider;
• the operator;
• the asset owner;
• the surrounding enterprise software.

This is essential for industrial assets whose operational lifecycle may last much longer than the software platform initially used to manage them.

Public and private Digital Twins

An ObjectID Digital Twin can be configured as public or private.

A public Twin can be discovered through the anonymous ObjectID Webview and accessed through its canonical URL.

A private Twin is excluded from anonymous discovery and appears in authenticated views associated with the relevant users.

The visibility setting controls discovery through the ObjectID Webview. It must not be interpreted as blockchain-level encryption.

Information written to the public IOTA network must always be treated as publicly readable.

For this reason, confidential telemetry, credentials, private documents and other sensitive data should remain off-chain.

Twin visibility and location visibility are also managed separately.

A public Twin does not automatically publish its geographical coordinates.

An Owner or Steward must explicitly publish a public location before the Twin receives a marker on the anonymous map.

Private coordinates can instead be stored encrypted in the authenticated Webview without being written to IOTA.

This separation makes it possible to create:

• a public Twin with no public location;
• a public Twin with an approximate public location;
• a private Twin with a private operational location;
• a publicly discoverable identity with protected realtime data.

Use the hosted MQTT service or operate your own broker

ObjectID does not require every organization to use the hosted MQTT broker.

The public dtis.objectid.io service provides an ObjectID-operated MQTT endpoint with:

• dedicated tenant credentials;
• a dedicated MQTT username and password;
• topic ACLs limited to the customer’s Twins;
• separate state, dataset and command topics;
• credential rotation and revocation;
• downloadable integration configuration.

Integration credentials can be generated from the ObjectID Webview.

Secrets are displayed only once during generation or rotation. The downloaded configuration contains:

• the DTIS endpoint;
• the tenant API key;
• MQTT credentials;
• permitted Twin IDs;
• exact MQTT state topics;
• exact MQTT dataset topics;
• command request and result topics.

Organizations that want to retain their existing private MQTT infrastructure can deploy their own ObjectID Integration Server and connect that server to their broker.

The private broker can be deployed:

• inside an industrial network;
• on an edge gateway;
• in a private cloud;
• on a dedicated VPS;
• within an existing IoT infrastructure.

Devices continue to communicate through a widely adopted and lightweight messaging protocol.

The ObjectID Integration Server connects the MQTT environment to the corresponding Digital Twins.

It validates the tenant, subscription and Twin association, maps each permitted topic to the expected Twin and exposes operational data through an authenticated API.

The Webview never needs to connect directly to the MQTT broker.

This prevents MQTT credentials from being exposed to the browser and creates a controlled backend boundary between industrial infrastructure and user-facing applications.

The current MQTT connector supports:

• MQTT authentication;
• MQTT over TLS;
• server certificate validation;
• QoS configuration;
• wildcard subscriptions;
• explicit topic-to-Twin mappings;
• tenant-specific dynamic mappings;
• topic-level access control through the broker;
• encrypted payload envelopes.

If the MQTT broker and Integration Server remain inside a private network, they are not automatically exposed through ObjectID.

The organization decides whether realtime data should be reachable through:

• a public authenticated HTTPS endpoint;
• a VPN;
• a private Webview deployment;
• another protected network route.

Use your own storage

A self-hosted ObjectID Integration Server can use customer-operated filesystem or S3-compatible storage.

Supported storage categories include:

• telemetry datasets;
• documents;
• machine models;
• photographs;
• maintenance evidence;
• certificates;
• technical artifacts;
• event payloads.

The organization can control:

• the storage infrastructure;
• the storage account;
• the geographical region;
• backup policies;
• encryption policies;
• access permissions;
• retention periods;
• deletion policies.

The current hosted dtis.objectid.io deployment uses ObjectID-managed S3-compatible storage and applies a standard 30-day retention period.

In a self-hosted deployment, ObjectID does not need to become the custodian of the organization’s operational dataset.

This provides several important advantages:

• operational data can remain within the selected jurisdiction;
• existing backup policies can be retained;
• storage can remain inside private infrastructure;
• organizations can apply their own encryption and access controls;
• data can be deleted according to customer-defined policies;
• storage providers can change without changing the Twin identity;
• the blockchain stores integrity references instead of confidential payloads.

This model provides a concrete path to data sovereignty.

The organization can control where operational data is stored, who can retrieve it, how long it is retained and whether it is accessible outside the private network.

ObjectID provides the identity, governance and integrity layer needed to verify that data when required.

Privacy through architectural separation

Privacy in ObjectID Digital Twin does not depend only on hiding fields in a user interface.

It is built through separation between:

• public on-chain information;
• private Webview configuration;
• authenticated realtime information;
• off-chain operational data.

Information written to the public IOTA network must always be treated as publicly readable.

Information that may be intentionally published includes:

• the OIDTwin identifier;
• the public name and description;
• selected metadata;
• an approximate public location;
• lifecycle and revision events;
• resource references and integrity hashes.

Private off-chain information can include:

• realtime telemetry;
• exact private coordinates;
• MQTT credentials;
• API credentials;
• device decryption passwords;
• private documents;
• internal command history;
• operational parameters.

Sensitive Webview configuration and private locations are encrypted at rest.

External API and MQTT secrets are displayed once during generation or rotation and are not returned afterwards.

Devices may also encrypt MQTT payloads using AES-256-GCM before transmission.

In that configuration, the Integration Server transports and stores the encrypted envelope without receiving the device decryption password.

A Twin may therefore remain publicly identifiable and independently verifiable without making its operational dataset public.

One public identity, multiple private implementations

A Digital Twin can have a canonical public URL and QR code.

For example:

https://dt-demo.objectid.io/twin/0x1ea833a44afc8c0a22ea17d8d4e924333669519e225a0bb03c64744b3bd1dd2f

Anyone opening the URL can access the information intentionally published for that Twin.

An authenticated and authorized user opening the same URL can access additional operational information when the Twin is associated with an accessible Integration Server.

The public identity remains stable while the underlying MQTT broker, Integration Server and storage infrastructure can remain private or change over time.

This creates a powerful model:

• the identity can be public;
• ownership can be verifiable;
• integrity evidence can be anchored on-chain;
• telemetry can remain private;
• infrastructure can remain customer-controlled.
• Signed and auditable commands

ObjectID Digital Twin can also dispatch operational commands to authorized Twins.

The user authenticates through a decentralized identity and locally signs the command intent.

Before MQTT dispatch, the platform verifies:

• the requester’s identity;
• the signature of the command intent;
• the requester’s relationship with the Twin;
• the selected command catalog;
• the supplied parameters;
• the request timestamp;
• the request expiration;
• the command identifier and idempotency information.

The Integration Server then creates a command record and publishes an authenticated command envelope to the MQTT broker.

The device can validate, execute and acknowledge the request.

The resulting operational sequence is:

1. signed user intent;
2. DTIS authorization and role validation;
3. allowlisted command validation;
4. HMAC-authenticated MQTT dispatch;
5. device acknowledgement;
6. execution status;
7. persisted DTIS command record.

The ObjectID Move package also defines on-chain command objects and command lifecycle events.

Automatic on-chain anchoring of every MQTT dispatch and execution result is not yet part of the currently deployed command path. It can be integrated when blockchain evidence is required for a specific command workflow.

ObjectID commands are intended for accountable operational orchestration.

They do not replace:

• emergency-stop systems;
• safety PLCs;
• machine interlocks;
• certified industrial safety controls.

Safety-relevant commands are explicitly rejected by the general ObjectID command channel.

A subscription model separated from blockchain gas

ObjectID Digital Twin separates service accounting from blockchain gas management.

Each customer has an on-chain SubscriptionAccount containing:

• the subscription plan;
• the current billing period;
• the maximum number of active Twins;
• the monthly operation allowance;
• current usage;
• the Integration Server assigned to the subscription.

Subscription operations consume service credits.

Blockchain gas is paid separately by ObjectID through the ObjectID Gas Station for the controlled Digital Twin package.

This means devices and users do not need to hold IOTA tokens to perform normal supported operations through the Integration Server.

The Integration Server validates the customer subscription before executing operations.

A customer-operated Integration Server uses the same model: it must be explicitly assigned to the customer subscription and can operate only on Twins for which the required on-chain authority and tenant relationship exist.

Possession of an API key alone does not grant authority over another customer’s Twin.

A Digital Twin that is not locked into one platform

The fundamental innovation behind ObjectID Digital Twin is not one individual feature.

It is the ability to combine a standardized architecture and a shared verification layer with hosted or privately operated infrastructure.

Organizations using a self-hosted deployment can maintain control of:

• their devices;
• their MQTT broker;
• their Integration Server;
• their operational network;
• their encryption keys;
• their storage;
• their retention policies;
• their confidential data.

At the same time, they gain:

• persistent Digital Twin identities;
• on-chain ownership and governance;
• blockchain-anchored integrity evidence;
• verifiable lifecycle history;
• public or private discovery;
• QR-based access;
• authenticated operational views;
• signed command workflows;
• subscription-based operation accounting;
• sponsored blockchain gas (no need to buy cryptocurrency and manage wallets).

This reduces dependence on a single cloud platform and helps prevent the Digital Twin’s identity from disappearing when an application, infrastructure component or service provider changes.

The ObjectID Digital Twin proposition

ObjectID Digital Twin is built around four commitments.

Standardized architecture

Designed in architectural alignment with the ISO/IEC 30188:2026 Digital Twin reference architecture.

Verifiable trust

Identity, authority, lifecycle events and integrity evidence can be anchored through the IOTA-based ObjectID trust layer.

Flexible connectivity

Organizations can use the hosted ObjectID MQTT service or deploy their own Integration Server and MQTT broker.

Customer-controlled infrastructure

Organizations using a self-hosted deployment can operate their own storage and retain control over the location, accessibility, encryption and lifecycle of operational data.

This is the difference between simply visualizing an asset and creating a Digital Twin that can remain trusted across organizations, systems and time.

Explore ObjectID Digital Twin

ObjectID Digital Twin:

https://objectid.io/digital-twin/

Live Digital Twin Webview:

https://dt-demo.objectid.io/

Machine simulator:

https://dt-simulator.objectid.io/

Technical documentation:

https://dt-demo.objectid.io/docs

Open-source Integration Server:

https://github.com/ObjectID-io/digital-twin-integration-server

ISO/IEC 30188:2026:

https://www.iso.org/standard/53308.html

Start with ObjectID’s hosted integration service, or operate your own Integration Server, MQTT broker and storage.

One persistent Digital Twin identity, with verifiable governance and customer-controlled deployment options.

We are open to collaborating with machine builders and Digital Twin platform providers that want to add persistent identity, verifiable evidence and customer-controlled integration to their products and solutions.

For questions or collaboration opportunities:

info@objectid.io

#ObjectID #DigitalTwin #ISOIEC30188 #IOTA #Blockchain #MQTT #DataSovereignty #IndustrialIoT #IIoT #Industry40 #SmartManufacturing