Join our Newsletter — 33% off our NHI Course
Home› FAQ› Foundations & NHI Taxonomy› What happens when organisations use blockchain without PKI…
Foundations & NHI Taxonomy

What happens when organisations use blockchain without PKI for secure identity and communications?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated September 25, 2026 Domain: Foundations & NHI Taxonomy

Without PKI, blockchain cannot reliably prove who owns a key or who is allowed to participate in a transaction. That creates a gap in identity assurance even if the ledger itself is tamper resistant. Organisations may preserve records, but they still struggle with authentication, encrypted communications, and trusted access decisions across devices or counterparties.

Why blockchain still needs PKI for identity and communications

Blockchain gives you an append-only record and a shared state machine, but it does not, by itself, establish trustworthy identity between participants. Secure identity and communications still depend on verified key ownership, certificate trust chains, and a way to bind an endpoint or actor to a public key before anyone treats a transaction or channel as legitimate.

Without PKI, the organisation often has a ledger that is harder to tamper with but easier to misattribute. That means the system can preserve data integrity while still leaving gaps in authentication, trust establishment, and encrypted channel setup across devices, services, and counterparties.

In practice, PKI supplies the trust fabric that blockchain does not natively provide: certificate issuance, revocation, and a policy-backed way to say which key belongs to which entity. In other words, blockchain can record what happened, but PKI helps determine who was authorised to make it happen and who is allowed to communicate securely in the first place.

What fails when key ownership is not proven

The main failure is not ledger corruption, it is identity ambiguity. If a platform cannot reliably bind a public key to a real participant, then signing a transaction or opening a secure session proves possession of a key, not that the key belongs to the right party or is still trusted.

That creates weak authentication, weak access decisions, and poor lifecycle control for certificates or keys. It also complicates revocation, because the organisation may not have a clean trust store or certificate authority process to withdraw access when a device, service, or counterparty should no longer be trusted.

For communications, the absence of PKI usually shows up as ad hoc trust bootstrapping, manual key exchange, or reused keys with unclear ownership. Those patterns make it difficult to scale secure messaging, mutual authentication, and encrypted connections without adding custom trust logic around the blockchain layer.

Why the blockchain ledger does not solve secure communications

A blockchain can anchor records, hashes, or metadata, but it does not automatically secure the transport channel or prove endpoint authenticity. If two systems need encrypted communications, they still need a trust model for certificates, key exchange, and session establishment, which is where PKI normally does the heavy lifting.

This distinction matters because secure identity and secure messaging are related but not identical. A tamper-resistant ledger can help with auditability and nonrepudiation, yet it cannot substitute for certificate issuance, revocation checking, or policy decisions about which identities may connect, sign, decrypt, or delegate.

Where organisations try to skip PKI, they usually end up rebuilding trust controls in application code, which increases operational complexity and creates inconsistent verification rules. A better pattern is to treat the blockchain as a record and coordination layer, then use external trust infrastructure for identity proofing and communication security.

Risk and Threat Considerations

Using blockchain without PKI shifts trust from verified identities to brittle assumptions about key ownership and network membership. That can expose the organisation to impersonation, unauthorised participation, and insecure channel setup even when the underlying ledger remains intact.

Failure mechanism: An attacker or untrusted party can present a valid-looking key or reuse an unverified key pair, and the system has no strong certificate-backed method to prove who the key belongs to or whether it should still be trusted.

Impact: The organisation may accept forged transactions, allow the wrong counterparties into secure communications, or fail to revoke access cleanly after compromise, creating integrity and access-control failures that the blockchain alone cannot prevent.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.

FrameworkControl / ReferenceRelevance
NIST SP 800-53 Rev 5IA-2 — Identification and Authentication (Organizational Users)Identity proof is central when blockchain participants must be known and trusted.
IA-5 — Authenticator ManagementThe question hinges on trusted key and certificate lifecycle control without PKI.
SC-12 — Cryptographic Key Establishment and ManagementSecure communications need trustworthy key establishment even when the ledger is tamper resistant.
Recommendation — Require verified authentication before allowing organizational users to sign or submit transactions. Manage issuance, storage, rotation, and revocation of authenticators with a defined lifecycle. Establish and manage cryptographic keys through controlled, policy-backed processes.

Practitioner Guidance

What to verify: Confirm that every participating device, service, or external counterparty has a defined trust anchor, an issuance process, and a revocation path before you rely on blockchain records for security decisions. If you cannot answer who vouches for the key, the trust model is incomplete.

Decision rule: If the blockchain is being used to support authentication, encrypted communications, or authorisation decisions, treat PKI or an equivalent trust service as a required control, not an optional enhancement. If the use case is only shared auditability, the trust requirement is narrower.

Practitioner takeaway: Blockchain can make records durable, but it does not make identities trustworthy on its own, so secure deployments must separate ledger integrity from identity assurance and communication trust.

Deepen Your Knowledge

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Reviewed and updated by the NHIMG editorial team on September 25, 2026.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org