A type whose meaning comes from the value it holds rather than the memory location of the object. Comparing these types by reference can produce unstable behaviour, especially in Java APIs where equals() expresses the real semantic relationship and identity checks do not.
Expanded Definition
A value-based type is a type designed so that its semantic meaning is carried by the value, not by object identity or memory location. In practice, that means two separate instances can represent the same logical entity, even though they are not the same object in memory. This matters most in language ecosystems such as Java, where NIST Cybersecurity Framework 2.0 is often used to structure governance around software correctness, resilience, and access integrity rather than runtime object internals.
Value-based types are commonly used for dates, identifiers, money-like abstractions, and immutable domain objects. Their design usually assumes comparison through equals-style semantics, not reference equality. The guidance is clear but implementation patterns vary across vendors and libraries, so developers must read the type contract carefully. A value-based type may be immutable, may disallow synchronization on instances, and may discourage identity-sensitive operations such as caching assumptions based on object address. When code treats such a type as though object identity were meaningful, subtle bugs can emerge in collections, serialization, concurrency, and API boundaries.
The most common misapplication is using reference checks or identity-sensitive logic on objects whose contract says that equality is defined by value, which occurs when developers assume two instances must be different because they are different objects.
Examples and Use Cases
Implementing value-based types rigorously often introduces API constraints, requiring teams to weigh simpler semantics against the loss of identity-oriented shortcuts such as reference-based caching or object-specific locking.
- Java java.time classes such as LocalDate are treated as values, so two instances for the same date should behave equivalently in comparisons and business rules.
- A payment amount object can encapsulate currency and numeric value, allowing business logic to compare the amount content rather than object identity.
- An access-policy rule object in a security platform can be value-based if its meaning comes from the rule definition, not from where it was instantiated.
- A configuration token or environment descriptor can be modelled as a value when the important question is whether the content matches, not whether the same in-memory object was reused.
- For identity-heavy systems, value-based semantics can help avoid brittle assumptions when objects are reconstructed after deserialization, replication, or message passing. Java developers often combine this with the equality guidance in the Object equals contract and the broader design direction in OWASP Secure Coding Practices.
Why It Matters for Security Teams
Security teams care about value-based types because incorrect identity assumptions can create authorization drift, inconsistent policy evaluation, and fragile audit logic. If a system uses object reference instead of semantic equality, the same user, policy, or token state may be interpreted differently across requests, services, or threads. That can lead to duplicate processing, broken deduplication, flawed comparisons in access decisions, or unreliable cache behaviour in security-sensitive components.
For identity and access systems, the distinction is especially important when objects represent credentials, sessions, claims, or policy artefacts that may be rehydrated from storage or transmitted across boundaries. A value-oriented design supports stable comparison and more predictable enforcement, while reference-oriented assumptions can undermine trust in the data path. This is consistent with governance expectations in NIST Cybersecurity Framework 2.0 and with secure engineering guidance that favours explicit, testable semantics over hidden object identity.
Organisations typically encounter the operational impact only after a security review, incident replay, or failed access check exposes that the system compared the wrong thing, at which point value-based typing becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | CSF 2.0 stresses governed, testable system behaviour where semantics must be explicit. |
| NIST SP 800-53 Rev 5 | SA-8 | Security engineering guidance supports precise design requirements for software components. |
| NIST SP 800-63 | AAL2 | Digital identity systems depend on stable credential and assertion handling across boundaries. |
| OWASP Non-Human Identity Top 10 | NHI governance depends on consistent handling of tokens, secrets, and identity artefacts. | |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero trust relies on explicit, continuously evaluated state rather than implicit object identity. |
Model secrets and NHI artefacts by content so comparisons remain valid after rotation or rehydration.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
