Secure to use versus secure: why identity trust still fails

At a glance

What this is: A DigiCert case study arguing that cryptographic security alone does not guarantee trustworthy identity or safe user interaction.

Why it matters: It matters because IAM, NHI, and human identity programmes all rely on trust signals that can be technically valid yet operationally misleading.

👉 Read DigiCert's case study on why secure does not always mean secure to use

Context

Secure to use is the operational question behind many identity programmes: can users, systems, and downstream controls actually rely on the trust signal they are presented with? In the Zoner case study, the issue is not whether security controls exist, but whether authentication and trust information is clear enough to support safe decisions across email, website access, and data-in-transit protection.

That distinction matters for IAM and PKI governance because assurance is not the same as usability. A certificate can validate a domain or sender, yet still leave practitioners with weak trust comprehension, poor policy alignment, or blind spots in how identity signals are consumed by people and systems.

Key questions

Q: How should security teams handle trust signals when cryptography is already in place?

A: Treat trust as an operational outcome, not a certificate status. Security teams should test whether users and systems can correctly interpret sender, destination, and transport assurance in real workflows. If the signal is technically valid but misunderstood, the control has not delivered usable trust.

Q: Why can a system be secure yet still not secure to use?

A: Because technical protection and practical trust are different things. A site or message can be encrypted and authenticated, but if people cannot easily tell what the identity signal means, they may still make unsafe decisions. Governance has to cover comprehension, not just control deployment.

Q: What should IAM teams learn from PKI and certificate governance?

A: IAM teams should treat certificate-backed identity as part of the identity lifecycle, not a standalone technical layer. Issuance, renewal, revocation, and presentation all affect whether trust is actionable. The operational question is whether the identity signal supports the right decision at the right point.

Q: How do organisations know whether trust controls are actually working?

A: Measure whether the intended trust signal changes behaviour in the workflow it was meant to protect. If users ignore the cue, systems cannot validate it consistently, or the policy is unclear, then the control exists but its trust value is weak.

Technical breakdown

Why cryptographic validity is not the same as trust usability

PKI proves properties such as domain control, certificate validity, and message or session integrity. It does not automatically prove that the trust signal is understandable, actionable, or consistently enforced by the organisation. Secure transport, authenticated email, and certificate-backed identity can all be technically correct while still failing if the consuming workflow does not make the trust decision obvious to users or downstream systems. That is why identity assurance and operational usability have to be assessed together, especially where certificates stand in for human judgement.

Practical implication: review whether certificate and authentication signals are actually usable in the workflows where trust decisions are made.

How email and website trust can diverge in practice

Email sender authentication and website destination assurance solve different trust problems. Email controls try to confirm who sent a message, while web controls try to confirm where a user is connecting and whether the session is protected in transit. Organisations often treat both as generic security, but the governance challenge is different: one protects message authenticity and the other protects destination confidence and transport integrity. If those signals are not surfaced clearly, users can still be led into poor decisions even when the underlying cryptography is working.

Practical implication: separate email identity assurance from web destination assurance in policy, monitoring, and user guidance.

What PKI governance misses when it focuses only on certificates

Certificate management is often framed as issuance, renewal, and revocation, but this case study points to a broader governance problem. Trust fails when people cannot tell whether the identity signal they see is meaningful enough to act on. That means certificate lifecycle controls alone are incomplete if the organisation does not also govern how trust indicators are presented, interpreted, and embedded into business processes. The control objective is not only to secure the channel, but to make the channel trustworthy in use.

Practical implication: align certificate lifecycle controls with how identity trust is communicated to users and systems.

NHI Mgmt Group analysis

Secure to use is a governance property, not a technical footnote. The Zoner case study shows that organisations can meet the technical bar for security while still failing the operational bar for trust clarity. PKI may validate identity, but if people cannot confidently interpret what the signal means, the control does not fully serve its purpose. For practitioners, this is a reminder that trust governance must include human comprehension and workflow fit, not only crypto status.

Certificate-backed identity is only as strong as the decision process around it. A valid certificate can support sender authentication or website assurance, but the surrounding policy determines whether that assurance is actionable. This is why PKI governance belongs alongside IAM and lifecycle management, not in a separate technical silo. The practitioner implication is that identity assurance must be consumable by both people and systems.

Trust signal usability: the real failure mode is not broken cryptography but ambiguous operational meaning. The article’s central point is that an environment can be almost 100 percent secured and still not be secure to use. That distinction exposes a recurring governance gap: controls are deployed, but their meaning is not made operationally reliable across channels. Practitioners should treat trust usability as a first-class control outcome.

Human identity and machine identity both depend on interpretable trust cues. Whether the actor is a person reading email or a system validating a certificate chain, the programme fails if identity evidence cannot be consumed correctly. That makes the lesson broader than PKI alone: identity governance has to cover issuance, interpretation, and enforcement together. For practitioners, the next step is to test trust signals in the workflows that actually depend on them.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A separate finding from the same research shows that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs.
• That confidence gap is a reminder that identity trust only works when governance can see and interpret the signals it is expected to enforce.

What this signals

Trust signal usability: the lesson from this case study is that control validity and control usability are not the same thing. In identity programmes, the point is not simply to prove that a certificate, sender check, or transport channel exists. The point is to ensure the signal changes behaviour in the workflow where trust is actually consumed, whether by users, administrators, or automated systems.

The broader signal for practitioners is that trust governance should be tested in context, not on paper. Programmes built around certificate issuance and renewal can still leave confusion at the point of use, which is where identity risk becomes operational. That is why PKI, IAM, and user-facing trust cues need to be reviewed together rather than as separate disciplines.

For teams maturing identity controls, the next priority is to map where trust decisions are made and whether the signal is intelligible at that moment. In practice, that means checking email authentication, web destination confidence, and certificate lifecycle operations as one end-to-end trust path, not as isolated technical tasks.

For practitioners

• Audit trust signal usability Review whether users and systems can correctly interpret certificate, sender-authentication, and destination-assurance signals in the workflows where trust decisions are made.
• Separate email and web assurance controls Treat email sender authentication and website destination assurance as distinct control domains with separate policy, monitoring, and incident response playbooks.
• Map PKI controls to business decisions Identify where certificate lifecycle events affect user trust, customer communication, and application behaviour, then align those touchpoints with IAM and security governance.
• Test trust comprehension with real workflows Validate whether people and systems respond correctly to trust indicators during login, message handling, and web navigation rather than assuming the certificate itself is sufficient.

Key takeaways

• Identity security is incomplete when controls are technically sound but operationally unclear to the people and systems that depend on them.
• PKI, email authentication, and website assurance need governance that covers interpretation and usability, not only issuance and validation.
• Practitioners should test whether trust signals actually change behaviour in live workflows before treating them as effective controls.

Key terms

• Secure To Use: A security state where a control is not only technically valid but also understandable and actionable in the workflow where it is consumed. It matters because identity assurance can fail operationally even when the underlying cryptography, authentication, or transport protection is working correctly.
• Certificate-Backed Identity: An identity assurance model that uses digital certificates to bind a subject, device, service, or domain to a trusted cryptographic identity. In practice, its value depends on issuance, renewal, revocation, and how clearly the trust signal is interpreted at the point of use.
• Trust Signal Usability: The degree to which a trust indicator can be correctly understood and acted on by the person or system that sees it. A usable signal changes behaviour at the decision point. If the indicator is ambiguous or ignored, the control may be valid but not operationally effective.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.

This post draws on content published by DigiCert: What is Secure to Use? | Zoner & DigiCert Partner Case Study. Read the original.