Trust, Trustworthiness, and Zero Trust: Why the Future of Trust Must Be Verifiable

Trust should not be maximized. It should be earned, evidenced, and continuously calibrated.

Almost every technology company claims to build trust.

But the phrase “trust us” already reveals the underlying problem: it asks for trust before providing sufficient grounds for it.

A software provider may claim that customer data is secure. A customer may believe that claim and decide to trust the provider. Whether the provider is actually trustworthy, however, is a different question. Only evidence about implemented security controls, their effectiveness, their scope, and their continued operation can provide a rational basis for that trust.

This is where concepts such as trust, trustworthiness, assurance, reliance, compliance, digital trust, and Zero Trust are often mixed together. Yet they describe different aspects of the same problem.

Understanding these distinctions helps us answer a much larger question:

What should trust mean in a digital world in which systems, organizations, and risks change continuously?

Trust begins where certainty ends

Across organizational and psychological research, trust is commonly associated with a willingness to accept vulnerability.

Rousseau et al. describe trust as a psychological state involving the intention to accept vulnerability based on positive expectations about another party’s intentions or behavior [1]. Mayer, Davis, and Schoorman similarly define trust as a willingness to become vulnerable to another party, even when that party cannot be completely monitored or controlled [2]. (ResearchGate)

Trust therefore requires at least two conditions:

There must be uncertainty, and something meaningful must be at stake.

When an outcome is completely certain, trust is unnecessary. When no potential loss or dependency exists, what appears to be trust may simply be convenience. Trust becomes relevant when we depend on another person, organization, or system and that dependency creates vulnerability.

This also means that trust is never merely a universal property of an entity.

A more precise formulation would be:

A trusts B with respect to X, under conditions Y, at a particular point in time.

A company may trust a cloud provider to store public marketing material but not automatically trust the same provider to process highly sensitive health information. A system may be sufficiently reliable for one use case while being entirely inappropriate for another.

Trust is therefore relational, context-specific, and risk-dependent.

Being trusted is not the same as being trustworthy

In everyday language, “trusted” and “trustworthy” are often treated as synonyms. Conceptually, however, they describe two different things.

Trusted means that an entity is actually given trust.

Trustworthy means that the entity deserves that trust.

A convincing fraudster may be trusted without being trustworthy. Conversely, a carefully engineered and well-governed system may be trustworthy but still fail to gain user trust because its capabilities, controls, and limitations remain invisible.

Mayer et al. identify three widely used dimensions of perceived trustworthiness: ability, integrity, and benevolence [2].

Ability refers to whether the trusted party is competent enough to perform the relevant task.

Integrity refers to whether its statements, principles, and actual behavior are consistent.

Benevolence refers to whether it is expected to consider the interests of the trusting party rather than exclusively pursuing its own advantage. (JSTOR)

For technical systems, these dimensions need to be translated.

Ability becomes technical capability, reliability, resilience, and security.

Integrity becomes predictable behavior, consistent rules, traceable processing, and truthful communication about limitations.

Benevolence cannot simply be attributed to a machine. It can, however, be assessed in relation to the organization that develops and operates the system: Does the organization protect users’ interests? Does it communicate risks honestly? Does it provide mechanisms for accountability and redress?

NIST approaches trustworthiness from a systems-engineering perspective. A trustworthy system is not merely one that people happen to trust. Its trustworthiness must be grounded in evidence that it can satisfy the critical requirements placed upon it. Depending on the context, these requirements may include security, safety, reliability, resilience, privacy, or other system properties [3].

That distinction is fundamental:

Trust exists in the mind of the trusting party. Trustworthiness exists in the qualities and behavior of the trusted entity.

The two can align, but they do not align automatically.

Trust, reliance, and compliance are not the same

Another important distinction exists between trust and reliance.

Trust is an attitude, expectation, or judgment.

Reliance is observable behavior.

A person may distrust an AI system and still follow its recommendation because no alternative is available, because time pressure is high, or because the organizational process requires it. Conversely, a person may generally trust a system but intentionally disregard its recommendation in a specific case.

This distinction matters because surveys asking users whether they trust a system do not necessarily predict when those users will rely on it. Recent human–AI interaction research therefore increasingly separates perceived trust, behavioral reliance, system performance, and the appropriateness of the resulting decision [8]–[10]. (ACM Digital Library)

Compliance is also not equivalent to trustworthiness.

Compliance initially answers a narrower question:

Have a defined set of requirements been satisfied within a defined scope?

A certification, audit report, or assessment may provide an important reason for trust. It is not, however, an unlimited and permanent statement that an organization is secure.

An audit may confirm that a particular management system was appropriately implemented within a particular scope and during a particular period. It does not automatically prove that every current configuration is correct, every newly introduced system is covered, or no security incident can occur.

NIST therefore cautions against treating compliance as the sole evidentiary basis for assurance or trustworthiness. Compliance can contribute valuable evidence, but a compliance-only approach may establish an appearance of security without adequately demonstrating the effectiveness of the underlying system [3]. (NIST Publikationen)

Compliance matters.

But compliance is one contributor to justified trust, not a complete substitute for it.

Assurance connects trust with trustworthiness

Between a party’s subjective trust and a system’s actual trustworthiness lies another concept: assurance.

NIST describes assurance in terms of the grounds for justified confidence that a claim has been or will be satisfied [3].

Assurance is therefore neither a feeling nor a guarantee. It is a structured justification.

A robust assurance structure should make at least five elements visible:

Claims: What exactly is being asserted?

Arguments: Why should the available information support the claim?

Evidence: Which records, observations, tests, or artifacts demonstrate implementation and effectiveness?

Assumptions: Under which conditions does the conclusion remain valid?

Scope: Which systems, processes, data, locations, and periods are covered?

NIST uses the concept of an assurance case to describe a structured and reviewable relationship between claims, arguments, assumptions, and supporting evidence [3].

Consider the following security claim:

All production data is encrypted at rest.

A corporate encryption policy demonstrates that an intention and requirement exist. It does not prove that every production storage system actually implements the requirement.

A screenshot from one database configuration provides evidence about that particular database at a particular moment. It does not necessarily demonstrate complete coverage.

A stronger assurance case might combine:

• a complete inventory of production data stores,
• configuration data from each relevant system,
• key-management requirements,
• automated configuration checks,
• test results,
• monitoring data,
• responsible owners,
• review records,
• and a clear timestamp for each piece of evidence.

The different forms of evidence serve different purposes.

A policy supports the intended design.

A configuration supports the technical implementation.

A test or continuous telemetry supports the actual operation.

A review supports the conclusion that the evidence was evaluated and accepted by an accountable party.

None of these elements is necessarily sufficient on its own. Assurance arises from the traceable relationship between the original claim, the covered scope, the implementation, and the available evidence.

A mature assurance system must also be capable of producing negative conclusions. It should be able to state that:

• the available evidence is insufficient,
• the evidence is outdated,
• part of the relevant scope is missing,
• the implementation contradicts the claim,
• an assumption can no longer be supported,
• or operational effectiveness has not yet been demonstrated.

NIST explicitly recognizes that an assurance analysis may produce unfavorable results when the evidence does not support the claim [3]. (NIST Publikationen)

A system that can only generate green check marks may create reassurance.

It does not necessarily create credible assurance.

Zero Trust does not mean trusting nobody

At first glance, Zero Trust appears to contradict the goal of building more trust.

It does not.

Zero Trust addresses a different level of the problem. It is not primarily a psychological or cultural philosophy. It is an architectural approach to access decisions.

Under a Zero Trust model, trust is not granted merely because a user or device is located inside a corporate network, belongs to the organization, or has previously been authenticated. Access is evaluated in relation to a specific resource, identity, device, context, and request. Permissions should be limited, continuously reassessed, and granted under the assumption that a network or system may already be compromised [4].

Traditional perimeter-based security often compresses a complex trust decision into one broad assumption:

Inside the corporate network means trustworthy.

Zero Trust decomposes that assumption into smaller decisions:

May this identity, using this device, under these conditions, access this resource now?

Zero Trust is therefore not the end of trust.

It is the end of implicit, broad, and permanently inherited trust.

A more precise interpretation would be:

Zero implicit trust. Zero unearned privilege.

An organization can have a high-trust culture and a Zero Trust architecture at the same time. Employees do not have to personally suspect one another simply because access decisions are technically verified.

In fact, well-designed controls may make interpersonal trust easier. They reduce the likelihood that an individual mistake, compromised account, or malicious request results in unlimited damage.

Zero Trust replaces one large and vague trust assumption with many smaller, contextual, temporary, and revocable decisions.

That is highly compatible with a modern understanding of trust.

Digital trust expands the perspective

Trustworthiness often focuses on the qualities of a particular organization, system, or relationship.

Digital trust broadens the perspective to an entire digital ecosystem.

The World Economic Forum describes digital trust as the expectation that digital technologies and services, as well as the organizations providing them, will protect stakeholder interests and uphold relevant societal expectations and values. Its framework connects digital trust with dimensions such as cybersecurity, privacy, transparency, auditability, fairness, interoperability, safety, and mechanisms for redress [5]. (World Economic Forum)

ISACA similarly frames digital trust around confidence in the integrity of relationships, interactions, and transactions across a digital ecosystem composed of people, organizations, processes, information, and technologies [6]. (ISACA)

This ecosystem perspective matters because the trustworthiness of a digital product rarely depends on that product alone.

A SaaS provider may rely on:

• a cloud infrastructure provider,
• an identity provider,
• software libraries,
• payment services,
• monitoring platforms,
• external data sources,
• and possibly third-party AI models.

The trustworthiness of the visible product therefore also depends on controls, assumptions, and dependencies that remain largely invisible to its users.

Digital trust can be understood as the broader economic and societal outcome.

Trustworthiness describes the properties that make the ecosystem deserving of trust.

Assurance provides the bridge between those properties and a stakeholder’s decision to trust.

AI demonstrates why maximizing trust is the wrong objective

Artificial intelligence makes the difference between perceived trust and actual trustworthiness particularly visible.

An AI system can communicate fluently, confidently, and persuasively without being consistently correct. An interface can signal transparency and competence even when the underlying model is not sufficiently reliable for the intended task.

Explanations, confidence scores, or human-like language may influence users’ perceptions. They are not automatically evidence that an answer is correct.

NIST therefore does not define trustworthy AI through a single property. The AI Risk Management Framework identifies multiple characteristics, including validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy, and the management of harmful bias. NIST also emphasizes that these characteristics are contextual and may involve trade-offs [7].

A system may be accurate but unfair.

It may be transparent but insecure.

It may preserve privacy but remain unreliable for its intended purpose.

It may perform well on average while failing unpredictably in the cases that matter most.

The label “trustworthy AI” must not obscure these distinctions.

Human–AI interaction research therefore increasingly discusses appropriate trust, calibrated trust, and appropriate reliance.

The objective is not to make users trust a system as much as possible. The objective is to help users form an accurate understanding of the system’s capabilities and limitations and rely on it only when that reliance is justified.

A systematic review by Mehrotra et al. found that there is still no single, consistently applied definition of appropriate trust across the literature. Research studies use different constructs and measurements for trust, intentions, reliance, perceived capability, and actual system performance [8]. (ACM Digital Library)

Visser et al. similarly distinguish trust, distrust, and appropriate reliance. Their review indicates that the empirical relationship between explainable AI, user trust, and appropriate reliance remains mixed and, in many contexts, inconclusive [9]. (ScienceDirect)

A 2026 preprint by Raees and Papangelis argues even more directly that subjective trust measurements do not automatically indicate whether people appropriately rely on AI recommendations. Because this work was published as a preprint, its conclusions should be treated as a current research contribution rather than a final consensus [10]. (arXiv)

Distrust is not necessarily the opposite of good system use either. A degree of skepticism may encourage verification and error detection. Yet indiscriminate distrust can also lead users to reject correct recommendations.

A 2026 experimental study by Peters, Biermeier, and Scharlau investigated whether visual attention could help identify “healthy distrust” in human–AI interaction. The findings were not conclusive and illustrate how difficult it remains to measure whether trust and distrust are appropriately calibrated [11]. (Frontiers)

The desired relationship can be illustrated as follows:

Actual trustworthiness	Low user trust	High user trust
Low	Justified skepticism	Dangerous overtrust
High	Undertrust or unnecessary non-use	Justified, calibrated trust

The objective is not simply to move every user into the bottom-right corner by increasing trust.

The objective is to make perceived trust and behavioral reliance correspond as closely as possible to the actual trustworthiness of the system, the consequences of failure, and the context of use.

In a July 2026 article, Busuioc and Maggetti argue for a shift from trust maximization toward calibrated trust. They warn that trust can become detached from actual trustworthiness when organizations manufacture signals of trust instead of addressing the underlying conditions that make trust justified. Their analysis also emphasizes vulnerability, accountability, and the constructive role that distrust can play [12]. (OUP Academic)

The European AI Act follows a related operational logic. For relevant high-risk systems, it requires processes and documentation concerning risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness, and cybersecurity [13].

These requirements do not prove that every regulated AI system will be trustworthy. They do, however, attempt to translate an abstract expectation of trustworthiness into concrete governance activities and reviewable evidence. (EUR-Lex)

Trustworthy AI is therefore not an interface style or a marketing label.

It is an ongoing governance and assurance problem.

Our position: trust must be justified and calibrated

At Secani, we do not understand trust as a feeling that should simply be increased.

Nor do we define it as absolute certainty.

Absolute security does not exist in real digital systems. Even strong evidence cannot guarantee that no failure or attack will ever occur. Evidence reduces uncertainty and supports better decisions, but it does not eliminate risk.

If all uncertainty could be removed, trust would no longer be necessary.

That is why we deliberately speak of justified confidence, not certainty.

Our definition is:

Trust is justified, context-specific confidence that a security claim is true now because the claim, its implementation, and the current evidence verifiably align.

The underlying chain is:

Claim → Implementation → Evidence → Assurance → Calibrated Trust

An organization makes a claim about its security.

That claim is translated into specific controls, systems, responsibilities, and expected outcomes.

Current evidence demonstrates whether and how those controls have been implemented.

An assurance process evaluates whether the evidence actually supports the original claim.

Only then does a rational basis for trust emerge.

This definition contains five deliberate constraints.

Trust is claim-specific

“We are secure” is too broad to be meaningfully verified.

“All production data stores use approved encryption configurations” is narrower and testable.

The more general a claim becomes, the more difficult it becomes to identify its scope, required evidence, assumptions, and conditions of validity.

Trust is context-specific

A control may be effective for one system and ineffective for another.

An AI model may be suitable for summarizing internal documents but unsuitable for autonomously approving security exceptions.

Trust cannot be transferred between contexts without evaluating whether the relevant conditions remain comparable.

Trust is time-dependent

Organizations change continuously.

New assets are introduced. Configurations are modified. Employees change roles. Suppliers update their services. Vulnerabilities are discovered. Controls that operated correctly yesterday may no longer operate correctly today.

Evidence therefore loses value over time.

A trustworthy conclusion must communicate not only what was verified, but also when it was verified and how long that conclusion should remain valid.

Trust is evidence-based but not absolute

Evidence makes uncertainty visible and decisions defensible.

It does not remove uncertainty entirely.

Even strong evidence has limitations. It may cover only part of a system, rely on assumptions, contain measurement errors, or become obsolete. Credible assurance must communicate these limitations rather than hiding them behind a binary status.

Trust must be revocable

A trust decision must be able to change when the supporting conditions change.

When new evidence contradicts a previous security claim, the conclusion should be updated. When evidence expires, confidence should decline. When the covered scope expands, additional evidence should be required.

Trust that cannot be revised is not calibrated trust.

It is belief detached from reality.

From periodic trust signals to continuous assurance

Traditional digital trust is often built through periodic signals:

Certificates, questionnaires, audit reports, assessment documents, and security presentations.

These mechanisms remain important. But they are not sufficient on their own in a world where digital systems can change every day.

The future model moves in a different direction:

Traditional model	Future model
“Trust us”	Verify a specific claim
Broad security promises	Defined claims and explicit scope
Periodic evidence collection	Continuously refreshed evidence
Static documents	Connected, machine-readable information
Binary compliance status	Context, uncertainty, and validity periods
Hidden assumptions	Explicit assumptions and dependencies
Positive evidence only	Visible gaps and contradictory evidence
One annual conclusion	Continuously revisable conclusions

Continuous assurance does not mean that every activity in an organization must be monitored permanently.

It should be risk-based and proportionate.

A critical claim concerning privileged access, production infrastructure, or sensitive customer data requires more current and stronger evidence than a low-impact administrative claim.

The important change is that trust no longer remains attached to a single document.

Requirements, implementations, evidence, reviews, findings, responsibilities, and dependencies should instead form a connected model.

Machine-readable structures can play an important role in this transition. They allow evidence to be reused across frameworks and assessments without stripping away its provenance, original scope, collection time, responsible owner, or limitations.

The future of trust is therefore not merely continuous.

It is granular, traceable, transferable, and revocable.

Zero Trust and high trust are not opposites

The different concepts can now be connected.

Zero Trust governs how individual access decisions are made.

Trustworthiness describes whether a system or organization deserves trust.

Assurance provides a structured justification for that conclusion.

Evidence supports claims about implementation and effectiveness.

Compliance assesses alignment with defined requirements.

Reliance describes whether someone actually depends on or follows a system.

Digital trust is the broader confidence that may emerge across the ecosystem.

Zero Trust prevents trust from being assumed without sufficient grounds.

Assurance demonstrates where trust is justified.

Compliance contributes structured requirements and review mechanisms.

Evidence connects statements with observable reality.

These concepts are therefore not competing visions. They are different parts of one coherent model.

The future is neither a universal “trust everyone” nor a cultural “trust no one.”

It is verifiable, calibrated trust.

What “Optimize for trust” means at Secani

“Optimize for trust” must not mean optimizing for the perception of trustworthiness.

It should not mean producing as many green check marks, badges, certificates, or broad security claims as possible.

It should not mean encouraging people to trust a system more than its actual properties justify.

For us, it means:

Do not optimize for being trusted. Optimize for being worthy of justified trust.

We are building Secani to connect security claims, requirements, implementations, and evidence continuously.

Trust should not arise solely from a persuasive presentation or a periodic compliance document. It should arise from a current, reviewable, and traceable justification.

The most concise expression of that idea may be:

Trust is not a promise. It is a continuously supported conclusion.

Organizations should not merely appear trustworthy.

They should be able to demonstrate why they deserve trust.

And people should not simply be asked to trust more.

They should be enabled to trust better.

References

[1] D. M. Rousseau, S. B. Sitkin, R. S. Burt, and C. Camerer, “Not So Different After All: A Cross-Discipline View of Trust,” Academy of Management Review, vol. 23, no. 3, pp. 393–404, 1998, doi: 10.5465/AMR.1998.926617. (DOI)

[2] R. C. Mayer, J. H. Davis, and F. D. Schoorman, “An Integrative Model of Organizational Trust,” Academy of Management Review, vol. 20, no. 3, pp. 709–734, 1995, doi: 10.5465/amr.1995.9508080335. (DOI)

[3] R. Ross, M. Winstead, and M. McEvilley, Engineering Trustworthy Secure Systems, NIST Special Publication 800-160, vol. 1, rev. 1, National Institute of Standards and Technology, Gaithersburg, MD, USA, Nov. 2022, doi: 10.6028/NIST.SP.800-160v1r1. (NIST Publikationen)

[4] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, Zero Trust Architecture, NIST Special Publication 800-207, National Institute of Standards and Technology, Gaithersburg, MD, USA, Aug. 2020, doi: 10.6028/NIST.SP.800-207. (NIST Computer Security Resource Center)

[5] World Economic Forum, Earning Digital Trust: Decision-Making for Trustworthy Technologies, Geneva, Switzerland, Nov. 2022. (World Economic Forum)

[6] K. B. Kelley, “The Digital Trust Imperative: Defining, Establishing and Measuring Digital Trust,” ISACA Journal, vol. 1, Jan. 2023. (ISACA)

[7] National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, Jan. 2023, doi: 10.6028/NIST.AI.100-1. (NIST Publikationen)

[8] S. Mehrotra, C. Degachi, O. Vereschak, C. M. Jonker, and M. L. Tielman, “A Systematic Review on Fostering Appropriate Trust in Human-AI Interaction: Trends, Opportunities and Challenges,” ACM Journal on Responsible Computing, vol. 1, no. 4, Art. no. 26, pp. 1–45, 2024, doi: 10.1145/3696449. (ACM Digital Library)

[9] R. Visser, T. M. Peters, I. Scharlau, and B. Hammer, “Trust, distrust, and appropriate reliance in (X)AI: A conceptual clarification of user trust and survey of its empirical evaluation,” Cognitive Systems Research, vol. 91, Art. no. 101357, 2025, doi: 10.1016/j.cogsys.2025.101357. (ScienceDirect)

[10] M. Raees and K. Papangelis, “From Trust to Appropriate Reliance: Measurement Constructs in Human-AI Decision-Making,” arXiv:2604.23896, Apr. 2026, doi: 10.48550/arXiv.2604.23896. Preprint. (arXiv)

[11] T. M. Peters, K. Biermeier, and I. Scharlau, “Assessing healthy distrust in human-AI interaction: Interpreting changes in visual attention,” Frontiers in Psychology, vol. 16, Art. no. 1694367, Jan. 2026, doi: 10.3389/fpsyg.2025.1694367. (Frontiers)

[12] M. Busuioc and M. Maggetti, “Worthy of trust? AI governance and the role of (dis)trust,” Perspectives on Public Management and Governance, Art. no. gvag007, Jul. 2026, doi: 10.1093/ppmgov/gvag007. (OUP Academic)

[13] European Parliament and Council of the European Union, “Regulation (EU) 2024/1689 of 13 June 2024 laying down harmonised rules on artificial intelligence,” Official Journal of the European Union, Jul. 2024. (EUR-Lex)