A blockchain proposal usually lands on the security team's agenda after the business case has already been made. A partner wants a shared ledger or a vendor promises tamper-resistant records, and security, architecture and risk leads are asked to approve a system whose risks look unfamiliar, even though many of them are not.

Blockchains do offer real integrity properties. Records are replicated across many nodes, new entries require agreement under a consensus mechanism, and confirmed transactions are designed to be hard to reverse. None of that makes the overall system secure by default. The ledger sits inside a stack of networks, servers, software, keys and people, and each layer can fail on its own terms.

The threat landscape, layer by layer

It helps to sort threats by where they land. The categories overlap, but they map well onto how enterprise teams already divide responsibility.

  • Network layer. Blockchains run on peer-to-peer networks. Distributed denial of service (DDoS) attacks can flood nodes with traffic until they crash or fall behind.
  • Consensus layer. The rules by which nodes agree on the next block can be subverted if one party gains outsized control, most famously through a 51% attack.
  • Node layer. Nodes can be attacked through software flaws, exposed services or weak administrative access. Attackers can also run their own nodes, flooding the network with fake identities (a Sybil attack) or cutting honest nodes off from peers (de-peering), so they can observe traffic, delay or block legitimate transactions and feed misleading data to nodes that rely on them.
  • Application layer. Smart contracts and decentralized applications (dApps) add code that holds and moves value, along with the bugs that come with any code. Oracles that bring off-chain data on-chain are a further dependency.
  • User layer. Many losses start with stolen keys or credentials, taken through malware, phishing and social engineering. Once an attacker controls a private key, they control whatever it can sign for.

Consensus attacks and what they teach

In a proof-of-work network, a 51% attack becomes possible when a single miner or coordinated group controls more than half of the network's mining power. With that majority, the attacker can build a competing version of the chain faster than everyone else and have it accepted as the valid history. They can then reverse their own recent transactions and spend the same coins twice, or stop other users' transactions from being confirmed.

The Verge network suffered this kind of attack. Its proof-of-work design accepted blocks from several different mining algorithms, intended to widen access to mining. A flaw in that design let attackers concentrate rented mining power on a single algorithm, take effective control of the chain and double spend against exchanges: they deposited coins, swapped them for another asset, then released a chain that erased the deposits. The lessons apply well beyond one network:

  • Security depends on how widely block production power is distributed as much as on the design of the algorithm. Concentration in a few mining pools or a few large stakers is a risk worth monitoring.
  • In proof-of-stake systems, broad distribution of stake and randomized validator selection make collusion harder.
  • Fast detection limits losses. Watching for unexpected forks or stalled block production lets operators and exchanges raise confirmation requirements or hold suspicious deposits before they clear.

Securing nodes and architecture

Organizations that run their own nodes, on a public network or a permissioned one shared with partners, take on the hardening duties of any internet-facing server plus some specific to consensus.

  • Minimize the attack surface. Run only the services the node needs, close unused ports and disable features that are not in use.
  • Patch promptly. Keep node software and the operating system current, ideally through automated patch management.
  • Restrict access. Filter traffic with firewalls and intrusion prevention, bind services to approved internal addresses instead of every interface, keep administrative access behind a VPN and require multi-factor authentication for any shell or console.
  • Provision headroom. Ample bandwidth, memory, storage and compute help nodes absorb traffic floods. Baseline resource use so spikes stand out.
  • Distribute. Spread nodes across regions and hosting providers so one outage does not take you offline.
  • Monitor consensus health. Track node health, consensus participation and block propagation. Stalled blocks or transactions that never confirm can signal de-peering or a consensus attack in progress.

Across the wider architecture, encrypt keys, credentials and network traffic, isolate signing services and wallets from other components, and apply least-privilege, role-based access to anyone who can deploy contracts or change configuration. Build on libraries with no known vulnerabilities, schedule regular audits and penetration tests, and in permissioned networks authenticate every node allowed to join.

Wallets, transactions and dApps

On a blockchain, whoever holds a private key can move the assets it controls, and confirmed transactions are designed to be irreversible. That makes key management the control that matters most for most organizations.

  • Treat keys and seed phrases as your most sensitive credentials. Never store them digitally without encryption. Offline backups kept in physically secure locations remove the remote attack surface.
  • Use hardware for sensitive signing. Hardware wallets and hardware security modules keep keys off internet-connected machines. Buy from reputable, well-reviewed suppliers, since cheap devices carry supply chain risk.
  • Avoid single points of failure. Multisignature policies require more than one approver for significant transactions, and documented recovery plans cover lost or compromised keys.
  • Vet software wallets. Use audited applications with a verified security record, installed only from official sources.
  • Train people. Phishing emails and messages that point to fake wallet sites are a common route to key theft. Staff should transact only on trusted devices and secured networks.

Smart contracts and dApps deserve their own review, covered in our separate article on smart contract and DeFi risk. At a minimum, contract code should be reviewed, tested and audited before deployment, privileged functions limited to authorized addresses, and inputs validated on both the client and the contract side. Any upgrade mechanism is itself a privileged path.

Assessing a blockchain solution with a security eye

Before any of these controls apply, someone has to decide whether blockchain is the right choice at all. These questions work well as a checklist for architecture and risk reviews:

  • Problem fit. What problem is the ledger meant to solve? Do several parties that do not fully trust each other need shared records? If one organization controls all the data, a centralized database may be faster, simpler and easier to secure.
  • Network model. Public permissionless networks offer the widest decentralization but demand more oversight. Permissioned networks restrict access and suit regulated data, at the cost of concentrating control.
  • Data sensitivity. How sensitive is the data, and what is the impact of a leak? Consider encryption, zero-knowledge proofs or a permissioned design, and remember that data written to an immutable ledger is difficult to correct or remove.
  • Compliance. Which obligations apply, such as anti-money laundering and know-your-customer rules, sector privacy rules, data protection law, data residency and retention? Confirm with legal counsel that the design allows the organization to meet them.
  • Participants. Can partners run nodes and uphold sound cybersecurity and key management? A weak participant weakens the whole network.
  • Identity. Pseudonymous addresses can undermine accountability, while managed identities introduce centralization and privacy questions.
  • Dependencies. How do oracles supply off-chain data, and what happens if one fails or is manipulated? Redundancy and monitoring reduce the risk.
  • Keys. Who holds signing keys, in what hardware, and under what multisignature and recovery policies?
  • Operations. Is there monitoring for anomalies, outages and unauthorized changes, and an incident response plan for scenarios such as key compromise, tested through exercises?
  • Sustainability. Energy-intensive proof-of-work networks raise environmental questions that proof-of-stake designs largely avoid.

Building a shared baseline

Security reviews stall when each function brings a different mental model. Security teams may not know how consensus finality works, architects may underestimate key management, and risk teams may not know which questions to ask. A shared foundation lets them assess proposals together and explain their conclusions to boards and auditors.

That is the purpose of the Blockchain+ certification, which has no prerequisite. Its courses are Web3 Foundations, Blockchain Foundations, Bitcoin Past, Present and Future, Blockchain Development Decision and Understanding L1 and L2 Blockchains.

The Web3 Academy delivers the training; the Web3 Certification Board (W3CB) sets the exam and issues the certification, with the exam seat included in the training price.