A ZoomEye count-only query for title="Eclipse Ditto" returned 317 matches on November 10, 2026. The app="Eclipse Ditto" query returned 0. Both used page 1, pagesize 1 and sub_type=all.
Eclipse Ditto is a digital twin framework. Its data model includes Things, Features and Policies. A Thing references a policy, and that policy defines which subjects may read or write the Thing or a narrower resource inside it.
The title count may include documentation, a developer portal or a deployed Ditto gateway. The zero application count does not prove that no Ditto instances are exposed. Fingerprint coverage can lag or vary by gateway configuration.
The count is small, but policy review remains important.
Policy is the object model
Ditto policy entries combine a subject, a resource and a permission. A resource can be as broad as thing:/ or as narrow as a feature or attribute. A subject may use a user identity, a pre-authenticated identity or a connection identity.
The policy also controls policy administration. A subject with write access to the policy can change who else can access the Thing. That is a different authority from writing a feature value, and it should be separated when the application supports it.
Review each policy for:
- 1.
Human and service subjects.
- 2.
Resource path scope.
- 3.
Read, write and policy-management permissions.
- 4.
Policy imports and namespace restrictions.
- 5.
Stale subjects and wildcard identities.
The exact feature set depends on the Ditto version. The review should use the schema accepted by the running deployment.
Connections assign their own subjects
Ditto connections can provide an authorizationContext with self-assigned subjects. Before a connection can access a resource, a policy must grant one of those subjects the required permission.
That design is powerful and easy to misread. A connection that injects a subject with broad access can become a bridge from an external message source into many Things. The policy remains the decision point, but the connection controls which identity the policy sees.
Audit connection configuration with the same care as user accounts. Record the connection ID, transport, target, injected subject and the policies that grant that subject access. Look for a shared subject used by multiple integrations where separate identities would provide better attribution.
Test the policy boundary
For a confirmed deployment, test with two subjects that have different policy entries. One may read a feature but not write it. Another may write a feature but not modify the policy. A third may have access only to a subtopic.
Send HTTP and WebSocket requests through the actual gateway. A policy that is correct in storage can still be bypassed by a proxy that injects or accepts the wrong subject header.
Review logs for policy changes, subject additions and connection configuration updates. A policy change is often more significant than a normal device update because it alters future authorization for every later message.
Keep the measurement bounded
The 317 title matches are not 317 confirmed management APIs. Use the count to plan a review of likely deployments, then verify the product through a controlled request.
For confirmed instances, export policies through the administrative API and compare them with the intended tenant model. Remove subjects that no longer exist and split policy-management permission from data-plane write access.
The useful outcome is a map from connection or user subject to Thing, feature and policy authority. A device count without that map says little about who can change a digital twin.