After the retirement of Azure Blockchain Service and Azure Blockchain Workbench, Azure blockchain in 2026 means using current Azure services and architecture patterns to build tamper-evident, multi-party, or verifiable systems.
Last updated: 2026. This article covers practical Azure options for blockchain-style workloads, including self-hosted permissioned networks on Azure Kubernetes Service, Azure SQL Database ledger, Azure Managed CCF, Azure Confidential Ledger and Microsoft Entra Verified ID. It does not present Azure Blockchain Service or Workbench as current managed offerings, and it does not assume that every audit or trust problem needs a blockchain.
What changed after Azure Blockchain Service and Workbench
Azure once offered services and templates intended to simplify enterprise blockchain deployment. Microsoft’s older material on Azure Blockchain Workbench is still useful historical context, but the important point for current planning is that those managed blockchain-era products should be treated as retired rather than as a deployment path for new systems.
The current Azure approach is more modular. Instead of one managed blockchain service, architects choose from services that solve narrower problems: tamper-evident database records, confidential append-only ledgers, decentralized credentials, confidential computing, or self-managed blockchain networks on Azure infrastructure. Microsoft Learn still provides an introduction to blockchain concepts, but production design now depends on matching the trust model to the right Azure building blocks.
That shift is healthy for many business systems. A previous generation of projects tried to use blockchain where a signed audit log, a governed database, or a verifiable credential would have been easier to operate. The stronger design question is no longer “How does the business use blockchain on Azure?” but “Which party needs to trust which record, who can write to it, and what evidence must survive a dispute?”
Choosing between blockchain, ledger databases, Managed CCF and Verified ID
The most useful decision criterion is ownership of writes. If several independent parties must submit transactions and no single administrator should be able to rewrite history unilaterally, a permissioned chain on AKS using clients such as Besu or GoQuorum may still be relevant. That design gives the parties shared governance, but it also makes the platform team responsible for node operations, upgrades, key custody, networking and long-term state growth.
If one organization owns the application and mainly needs tamper-evidence for records inside a relational system, a blockchain network is usually unnecessary. Azure SQL Database ledger can provide cryptographic evidence that data has not been altered outside the expected database operations, while keeping the query model, transactional behavior and operational tooling of SQL. It should be understood as a tamper-evident database capability rather than a decentralized blockchain.
Azure Managed CCF and Azure Confidential Ledger address a different class of requirement: append-only records protected by confidential computing and governance controls. They are most relevant when parties need an API-backed ledger with stronger integrity evidence than an ordinary application log, but do not want to operate a full blockchain network. Azure confidential computing services provide the hardware-backed execution environment that supports this model, and Microsoft describes the broader platform on its Azure confidential compute page.
Identity and credential scenarios should be separated from transaction-ledger scenarios. Microsoft Entra Verified ID is intended for issuing and verifying portable credentials, such as proof of employment, qualification or membership. It can complement a ledger system, but it is not a replacement for consensus, smart contracts or a database audit trail.
| Need | Likely Azure pattern | Main trade-off |
|---|
| Several organizations need shared write governance | Self-hosted permissioned chain on AKS | Highest operational responsibility |
| One administrator needs tamper-evident business records | Azure SQL Database ledger | Not decentralized governance |
| Applications need append-only APIs with confidential execution | Azure Managed CCF or Azure Confidential Ledger | Works best when the ledger API model fits the workflow |
| People or organizations need portable credentials | Microsoft Entra Verified ID | Solves credential verification, not transaction consensus |
Reference architecture: permissioned blockchain on AKS
A permissioned blockchain on Azure is now typically a self-managed architecture. The core pattern is a private AKS cluster running validator or member nodes, with private networking between consortium participants, Key Vault or managed HSM for key custody, Azure Monitor and Log Analytics for node health, and an event pipeline for indexing chain data into an analytics store. Application APIs can sit behind API Management or Front Door, while private endpoints reduce public exposure for supporting services.
Consortium participants
|
| private connectivity / peering / VPN
v
+-------------------------------+
| Private AKS cluster |
| - Validator nodes |
| - RPC/API services |
| - Smart contract services |
+-------------------------------+
| |
| +-- Key Vault or Managed HSM for keys
|
+-- Azure Monitor and Log Analytics for health and logs
|
+-- Event Hubs to analytics store for indexing and reporting
|
+-- API Management for controlled application access
This architecture can work, but it should be treated like a distributed systems platform rather than a simple application deployment. Validator keys need formal custody procedures, not ad hoc secrets in Kubernetes. Network rules should be designed for known consortium endpoints. Node upgrades require staging because client version mismatches can break participation, and state growth must be planned because ledger data tends to become expensive to move once production traffic accumulates.
From a practical perspective, teams that already operate Kubernetes may underestimate the difference between running stateless services and running consensus nodes. A bad rollout can interrupt block production, a mismanaged key can remove a member’s ability to sign, and weak observability can hide peer connectivity problems until transactions start failing. Azure-native controls help, but they do not remove the need for runbooks, test networks, backup procedures and governance agreements between participants.
Example — Kubernetes secret reference for an external key provider
The following simplified manifest illustrates the kind of separation platform teams should aim for: applications reference key material through an external secrets mechanism instead of storing validator keys directly in a deployment file. The exact provider configuration will vary by organization and should be aligned with Key Vault or managed HSM policies.
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: validator-key-reference
namespace: consortium-ledger
spec:
refreshInterval: 1h
secretStoreRef:
name: azure-key-vault-store
kind: SecretStore
target:
name: validator-signing-key
creationPolicy: Owner
data:
- secretKey: signing-key
remoteRef:
key: consortium-validator-signing-key
The example is not a full deployment pattern. Its purpose is to show an operational principle: validator identity should be controlled through managed key custody and auditable access paths, rather than being bundled into application configuration or copied across nodes manually.
Reference architecture: Managed CCF or confidential ledger API
Managed CCF and confidential ledger-style systems are better suited when the application needs an append-only, verifiable record exposed through APIs, without the complexity of a blockchain client network. The application submits signed transactions to the ledger service, retrieves receipts or proofs for later verification, and uses attestation evidence to support confidence in the execution environment.
- Business application
- signed ledger request
- +-------------------------------+
- | Managed CCF / confidential |
- | ledger API |
- | - Append-only transactions |
- | - Governance controls |
- | - Receipts or proofs |
- | - Attestation evidence |
- +-------------------------------+
- +-- Application database stores business state
- +-- Monitoring captures API health and request outcomes
- +-- Verification process checks receipts during audit or dispute
The design separates business state from audit evidence. The application database remains the operational source for queries and workflows, while the confidential ledger records critical events that need independent verification later. That separation is often easier to govern than placing every business action directly on a blockchain network.
Confidential computing adds another dimension to ledger design. In multi-party settings, participants may care not only that a record was appended, but also that approved code processed it in an expected environment. Attestation can provide evidence about that environment, although it should be built into the governance and verification process rather than treated as a blanket compliance guarantee.
Migration realities from retired Azure blockchain services
Migration from Azure Blockchain Service or Workbench-era implementations is rarely a clean lift-and-shift. Smart contracts may be reusable if they were written for compatible Ethereum clients, but the surrounding platform usually needs redesign. Workbench workflows, connectors, off-chain databases, identity integrations and reporting pipelines often contain as much business logic as the contracts themselves.
Quorum and Besu compatibility also needs careful testing. Chain configuration, genesis files, consensus settings, private transaction handling and account management can differ across environments. Contract addresses may remain stable only if deployment sequencing, nonces and chain history are preserved; otherwise downstream systems that reference addresses will need updates. Data indexing is another common migration issue, because analytics databases built from old chain events may need to be rebuilt, reconciled or reindexed from archived blocks.
A practical migration starts by classifying each component. The ledger state, smart contracts and historical events may be candidates for preservation. The managed service controls, Workbench abstractions and old integration layers usually need replacement. In many cases, the migration becomes an opportunity to ask whether the system still requires consensus, or whether SQL Database ledger, a confidential ledger, or Verified ID would now meet the audit and trust requirements with less operational risk.
Security, compliance and operational governance
Security for Azure ledger systems is a shared responsibility. Azure can provide managed identity, private networking, Key Vault, confidential computing, monitoring, policy controls and regional deployment options, but the customer design still determines who can administer nodes, rotate keys, approve governance changes, access ledger APIs and verify audit evidence. Compliance teams should be involved before implementation, because evidence that is technically strong may still be insufficient if governance does not match the regulatory expectation.
Regulators and auditors may accept tamper-evident database records when the key question is whether one organization altered its own data after the fact. They may expect multi-admin or multi-party governance when the record is meant to prove fairness between independent parties. That distinction matters: Azure SQL Database ledger can support auditability inside a single administrative domain, while a consortium chain or governed confidential ledger may be more appropriate where no one participant should control the evidence alone.
Data residency and privacy also need early attention. Blockchains and append-only ledgers are intentionally hard to rewrite, which can create tension with data minimization, retention and deletion requirements. A common mitigation is to store sensitive personal or commercial data off-chain and place hashes, references or signed events in the ledger. That design still requires careful threat modeling, because metadata, identifiers and transaction timing can reveal more than teams expect.
Where Azure Marketplace fits
Azure Marketplace can still help teams discover deployable blockchain-related solutions, partner offerings and infrastructure templates. It should be used as a sourcing channel rather than as proof that a given architecture is supported as a Microsoft-managed blockchain service. Each marketplace option needs review for operational ownership, upgrade path, identity integration, private networking, logging and long-term support.
This is particularly important for production systems that may outlive the product cycle of a template or vendor package. The durable assets are the architecture decisions, governance model, ledger data and integration contracts. Deployment convenience matters, but it should not outweigh portability and operational clarity.
Skills teams need for Azure ledger projects
Azure blockchain-style projects sit across cloud architecture, security, data engineering and distributed systems. Teams need enough Azure depth to design private networking, identity, monitoring and key management, and enough ledger knowledge to understand consensus, receipts, immutability and governance. A general Azure foundation is often more useful than narrow familiarity with retired blockchain tooling, especially when the solution may use SQL Database ledger or confidential computing instead of a chain.
For readers building that foundation, Readynez provides Microsoft Azure training that can support the platform skills behind these architectures. The training path should be chosen around the target role: architects need design trade-offs, platform engineers need operational controls, and security stakeholders need evidence, key management and compliance implications.
FAQ
Is Azure Blockchain Service still available for new projects?
No. Azure Blockchain Service and Azure Blockchain Workbench should be treated as retired offerings. New projects should evaluate current Azure patterns such as self-hosted permissioned networks on AKS, Azure SQL Database ledger, Azure Managed CCF, Azure Confidential Ledger and Microsoft Entra Verified ID.
Is Azure SQL Database ledger a blockchain?
No. Azure SQL Database ledger provides tamper-evident capabilities for relational data, but it does not provide decentralized consensus between independent writers. It is a strong option when one organization owns the database and needs evidence that records were not altered improperly.
When should a business use a permissioned blockchain on AKS?
A permissioned blockchain on AKS is most relevant when several independent parties need to write transactions under shared governance and no single administrator should control the record. The trade-off is operational responsibility for nodes, keys, upgrades, networking, monitoring and chain data growth.
Where does Microsoft Entra Verified ID fit?
Microsoft Entra Verified ID fits credential scenarios, such as issuing and verifying portable proofs about people or organizations. It can support identity workflows around a ledger system, but it does not replace a transaction ledger or smart contract platform.
Can existing Azure Blockchain Service projects be migrated directly?
Some components may move, especially smart contracts and historical ledger data where client compatibility allows it. However, Workbench workflows, integrations, reporting databases, identity assumptions and operational processes usually need redesign. Migration planning should include contract compatibility, chain configuration, address references and data reindexing.
Building on Azure without the old blockchain service
The key takeaway is that Azure still supports blockchain-style outcomes, but through more specific services and architecture choices. A project that needs shared writes across organizations may justify a permissioned chain on AKS. A project that needs tamper-evident relational records may be better served by SQL Database ledger. A project that needs confidential append-only evidence may fit Managed CCF or Azure Confidential Ledger, while credential portability belongs with Microsoft Entra Verified ID.
A practical next step is to define the trust model before selecting technology: who writes, who administers, who verifies, and what evidence must be produced later. Once that model is clear, Azure’s current services can be combined into a design that is easier to defend operationally and easier to explain to security, compliance and engineering stakeholders.
