airtable_6a99bb1cc841b-1

Web3 entrepreneurs and fledgling teams have a huge amount to think about, but forgetting to truly comprehend the importance of good network security is a major mistake. Here’s what you need to know.

Treating "decentralized" as synonymous with "secure”

One of the biggest mistakes you can make (but also one of the most common among Web3 founders) is assuming that because a blockchain itself is decentralized and protected by cryptography, everything built on top of it inherits that security. When you put it that way, it’s pretty easy to spot the flaw in the logic, but a worrying number of businesses are built on sand simply because their owners assume it’s as robust as the cliff it sits atop of.

In practice, most breaches happen at the edge. Bugs in smart contracts, compromised private keys, phishing attacks on team members (more on that below) or vulnerabilities in the off-chain infrastructure (APIs, admin panels, cloud services) that manage the protocol. The chain being secure says nothing about whether the surrounding systems are.

Forgetting the limitations of the infrastructure around you

Web3 teams are working at the very edge of development and progress, wrapped-up in their digital worlds and buried deep within some of the most advanced principles of the age. However, Web3 teams are also often distributed and remote-first. On the surface, that sounds ideal and exactly how a Web3 company should be. In practical terms, however, that means that teams are often tapping into work via old, dated, or vulnerable home office infrastructure – or, worse, public infrastructure.

Every time a team member travels, for instance, they are hopping between public networks, often with very little thought for the ‘legacy’ tricks that make the web a dangerous place to be.

A business VPN doesn't fix bad key management, but it closes off a real and preventable attack surface: it stops attackers on the same network from intercepting traffic or targeting exposed RPC endpoints and admin panels, and it lets teams restrict access to sensitive infrastructure (a node's admin interface, an internal dashboard) by IP allowlist rather than leaving it reachable from anywhere on the public internet.

Underestimating social engineering and human-layer attacks

Even if you’re pouring resources into your technical infrastructure, your team might not have the knowhow to keep themselves (or the business) safe. It’s like fitting an incredible, three-step metal lock on the front door of the house, but not teaching its occupants how to lock it. That door will just sit open, creaking under its own potential to keep the house safe.

There’s no quick and easy way to minimize the risk of social engineering attacks. Some companies pour thousands of dollars a year into the practice of ‘red teaming’, which involves closely monitoring key employees for signs of vulnerability to malicious attacks, and getting a team to pose as an attacking entity – sometimes for months at a time – with a review to identifying and reducing those weak spots.

Of course, regular team training also goes a very long way, particularly in the beginning. The truth of the matter is, however, that human-layer attacks are growing increasingly sophisticated. Phishing is now ‘complemented’ by vishing, whereby AI is used to form a very convincing impersonation of co-workers and CEOs, even with a very limited sample.

The only way to keep on top of the social engineering threat is to continually monitor and improve. You can’t afford to be complacent here.