Identity is not entity

Identity is an overloaded word in software. A dependable business workflow often needs three separate answers:

• Who or what is making the request?
• Which legal entity does the request, record or decision concern?
• What is the actor authorised to do?

Authentication helps answer the first question. Company identity answers the second. Permissions, policies and delegated authority answer the third.

All three can matter in the same workflow, but none is a substitute for another.

Three controls, three different questions

Authentication

• Question: Who or what is making the request?
• Typical evidence: An authenticator, credential, token or federated assertion associated with a person or software workload.
• It does not establish on its own: Which legally recognised company the business record or action concerns.

Company identity

• Question: Which legal entity are we dealing with?
• Typical evidence: Authoritative company records, identifiers, jurisdiction, status and relevant corporate relationships.
• It does not establish on its own: Whether the actor may perform the proposed action.

Authority and permission

• Question: What may this actor do, for whom and within what limits?
• Typical evidence: Roles, policies, mandates, delegation and transaction controls.
• It does not establish on its own: Whether the company named in the working data is the correct legal entity.

NIST's digital-identity guidance concerns users interacting with information systems and the authenticators used to claim a digital identity. AWS similarly distinguishes human users, software workloads, federated principals and roles in its identity-and-access model. These controls are essential, but their subject is the actor requesting access.

A company register answers a different question. Companies House, for example, records the registered name, number, office address, status and entity type of UK companies. Those attributes describe the legally recognised company—not the person or workload requesting access to a system.

The controls can succeed independently

Separating the questions makes failure easier to see.

• The correct user can be authenticated while the customer record points to the wrong subsidiary.
• The correct legal entity can be established while the user lacks authority to approve the action.
• The actor and company can both be correct while the evidence attached to the company is out of date or belongs to its parent group.

Calling all of this “identity” can hide which control has actually been completed. A green authentication result should not be interpreted as confirmation that the business object is the correct legal entity.

What company context should a system receive?

A useful company-identity result needs more than a matched name. Depending on the workflow, it may need to carry:

• the registered legal identity and the authoritative identifiers used to establish it;
• the jurisdiction, entity type and current status;
• relevant parent, subsidiary, ownership or control relationships;
• the scope of intelligence associated with the company;
• the source, effective date, confidence and explanation behind material attributes; and
• a record of changes or alternatives that a person or system may need to review.

GLEIF illustrates part of this distinction in its own data model. Level 1 data addresses “who is who”, while Level 2 records direct and ultimate accounting consolidating parents for entities in scope. Establishing the company and understanding its relationships are connected tasks, but they remain separate pieces of information.

A practical system boundary

Authentication and access-control systems should continue to establish the actor and enforce permissions. Company-identity infrastructure should establish the company context on which the business workflow operates.

That boundary allows a product to ask explicitly:

• Has the actor been authenticated?
• Which legal entity is the subject or counterparty?
• What relationships and intelligence are relevant to this action?
• What evidence supports that company context, and when was it checked?
• Is this actor authorised to take the proposed action?

The product's own rules still determine what happens next.

How Sustema ENTITY fits

Sustema is developing ENTITY as Trusted Company Identity Infrastructure. Its intended role is to provide governed company context through a shared API:

• Anchor a request to the corresponding legal identity using authoritative records.
• Map relevant ownership, control and corporate relationships while preserving distinct legal entities.
• Extend the identity with intelligence relevant to the workflow.
• Assure the result by retaining evidence and explanation, exposing confidence and monitoring change over time.

ENTITY does not replace authentication, permissions or the customer's business decision. It supplies the company understanding those controls and decisions may depend on.

External access is being prepared in controlled stages. We are qualifying suitable workflows now.

If your product, workflow or AI system can identify the actor but still has to establish the company behind the action, tell us where that uncertainty enters the process. We would like to understand what you are building and explore whether ENTITY could help.

Discuss your workflow