Every major crypto breach since 2022 carries the same underlying cause: not a flaw in the smart contracts, not a network-layer attack, but a failure of the people operating the system. The Bybit hack that saw $1.4 billion leave the exchange's cold wallets in February 2025 was not caused by a broken protocol. It succeeded because human operators approved a transaction they had not independently verified, and because the environment they worked in had not trained them to treat that verification as non-negotiable. That is a security culture failure.
Technology and process controls are only as strong as the people running them. A multi-signature wallet that can be bypassed because one signer feels social pressure to approve quickly is not a functioning control. A privileged access policy that gets waived for the CTO because questioning the founder feels politically difficult is not a functioning control. Security controls degrade in a weak culture. They become stronger in a strong one, because people compensate for gaps, escalate suspicious activity, and hold each other accountable without being told to.
This post is the flagship People-layer analysis in the Security4Web3 content library. It sets out what security culture actually is, why Web3 organisations are starting from an unusually poor baseline, how adversaries read and exploit that baseline, and what practical steps a team of five to fifty people can take to shift it.
1. What Is Security Culture?
Security culture is the set of shared values, beliefs, and habitual behaviours that determine how an organisation's people think about and act on security when no one is watching. It is not a training module. It is not a policy document. It is not the contents of an employee handbook. Those are artefacts of culture. Culture itself is what happens in the space between the rules.
The distinction matters because most organisations confuse security programmes with security culture. They deliver mandatory awareness training, circulate an acceptable use policy at onboarding, and consider the problem addressed. The training gets clicked through. The policy gets signed without being read. And when an attacker sends a convincing message to a developer at 11pm, the employee opens the attachment because no deeply held operating norm tells them to stop and escalate. The programme existed. The culture did not.
A genuine security culture produces behaviour that is consistent, instinctive, and self-reinforcing. A developer in a strong security culture pauses before opening an unsolicited file regardless of how trusted the sender appears, not because a policy says to, but because that is simply how people in this organisation behave. A finance officer declines to process a payment instruction that arrived through only one channel, not because the approval procedure requires a second confirmation, but because the idea of doing otherwise feels uncomfortable.
This is the standard worth aiming for. It is achievable. It requires deliberate, sustained effort from leadership, not a one-time intervention.
2. Why Web3 Organisations Are Culturally Vulnerable
The Web3 industry has a security culture problem that is structural, not incidental. Several defining characteristics of the sector combine to produce an environment that is unusually permissive to attackers.
The move-fast ethos. Speed of execution is a competitive virtue in Web3. Founders hire for it. Teams are celebrated for shipping. In this environment, security controls that slow down a decision are culturally coded as obstacles rather than safeguards. A developer who pauses to verify an unusual request risks appearing overcautious. A CFO who refuses to sign a transaction without out-of-band confirmation delays the deal. The social pressure runs entirely against the security-correct behaviour.
Small teams with enormous access. A Series A crypto exchange might have a three-person operations team with signing authority over hundreds of millions of dollars of assets. A DeFi protocol with $500 million in total value locked may be maintained by a team of eight developers, several of whom hold production keys. This concentration of access in a tiny headcount means that the failure of a single individual's judgement carries catastrophic consequences. There is no depth of redundant human verification.
Pseudonymous collaboration. Web3 teams routinely work alongside contractors, contributors, and counterparties they have never met in person and in some cases have never verified by any means other than a wallet address or a Discord handle. The absence of identity anchors makes impersonation trivially easy and makes the cultural norm of "trust but verify" difficult to operationalise. When the person you are approving a transaction for is someone you know only as a Telegram username, the social verification mechanisms that normally function as a cultural backstop do not apply.
Distrust of formal process. Many Web3 teams have an ideological commitment to decentralisation that extends, improperly, to distrust of institutional process in general. Security policies, approval workflows, and access controls are perceived as symptoms of the centralised structures the industry is supposed to replace. This is a category error: operational security controls protect the team and users, not a hierarchy. But the cultural resistance to formal process is real and must be consciously countered.
Developers with root access to production. In many Web3 organisations, the same developer who writes code also deploys it, holds the deployment keys, and has direct access to wallet infrastructure. There is no separation of duties, no change approval process, no least-privilege architecture. Every individual with broad system access is a single point of failure for a social engineering attack. And because these are technical staff rather than security-trained operators, the cultural norms around access discipline are often absent.
Founder-led decision making that bypasses controls. Founders at fast-moving Web3 firms frequently approve decisions by personal authority rather than through documented processes. When the CEO approves a vendor payment by WhatsApp message, the cultural signal to the rest of the organisation is that controls exist for other people. The informal bypass of process by leadership is one of the most destructive forces in any security culture because it communicates, precisely, that the controls are performative.
3. How Attackers Exploit Culture Gaps
Adversaries who target Web3 firms, whether nation-state actors or organised criminal groups, conduct reconnaissance on organisational culture before they act. They are looking for the specific gaps that the Web3 environment reliably produces.
Lazarus Group's TraderTraitor unit, the entity responsible for the largest crypto thefts ever recorded, consistently targets organisations where security is perceived as IT's problem rather than a personal responsibility. Their initial approach, a fake recruiter message on LinkedIn, does not contain malware. It is a slow trust-building exercise. The reason it works is that developers at crypto firms are not culturally primed to treat an unsolicited professional approach as a threat. The culture does not produce that reflex. See our detailed analysis of their tradecraft in Lazarus Group Crypto OpSec: How Nation-State Attackers Target Web3 Teams.
The Bybit case illustrates the downstream consequence of culture failure with particular clarity. The attack did not breach Bybit's smart contracts. It did not crack its private keys by brute force. It compromised a developer at Safe{Wallet}, a third-party interface provider, by exploiting the same culture vulnerability: an individual who trusted a contact and opened a file without escalating. From that single cultural failure, the attackers injected malicious JavaScript into the signing interface and waited. When Bybit's signers approved what appeared to be a routine transaction, they had no reason not to. Nothing in their operating culture told them to independently verify the transaction details outside the interface they were presented with.
"The Bybit hack cost $1.4 billion not because the smart contracts were broken, but because people approved a transaction they should not have. That is the defining statement about where Web3 security risk actually lives."
Attackers also exploit the absence of escalation culture. In organisations where raising a security concern feels like overreacting, or where the informal norm is to resolve ambiguity yourself rather than bother a colleague, suspicious interactions go unreported. A social engineering attempt that would have been caught by a second set of eyes succeeds because the target did not feel empowered to escalate. This is not a failure of intelligence or training. It is a failure of culture.
The secondary costs of a successful attack are also culturally determined. When a Web3 firm is breached, the damage extends far beyond the direct financial loss. User trust is destroyed. Regulatory scrutiny intensifies. Exchange listings are reviewed. Token value collapses. Insurance becomes unaffordable or unavailable. The board loses confidence in the team. These secondary consequences are not technical in nature. They are the product of the reputational and relational capital that a weak security culture was consuming long before the breach occurred. For a broader view of how these risks compound, see our analysis of Operational Risk Management for Crypto Organisations.
4. The Three Levels of Security Culture
Edgar Schein's model of organisational culture, developed over decades of research at MIT Sloan, identifies three levels at which culture operates. Applied to security, the model provides a precise diagnostic framework for understanding why security programmes so frequently fail to produce behavioural change.
Level 1: Artefacts. These are the visible, tangible elements of security culture: the written policies, the acceptable use agreement, the annual training completion certificate, the poster on the office wall about strong passwords. Artefacts are easy to produce and easy to audit. They demonstrate intent. They do not, on their own, change behaviour. Most compliance frameworks measure artefacts because they are measurable. This produces organisations that score well in audits and fail in real incidents.
Level 2: Espoused values. These are what leadership says about security: the CISO's all-hands presentation, the security section of the employee handbook, the executive messaging after a competitor is breached. Espoused values shape perception and aspiration. But they are only credible when they are consistent with observed leadership behaviour. When a CISO presents on the importance of multi-factor authentication and the founder's account lacks it, the espoused value is immediately undermined. When the CEO says "security is everyone's responsibility" and then approves a vendor payment over personal WhatsApp, the message received is that the stated values are for external consumption.
Level 3: Basic assumptions. These are the deeply held, largely unconscious beliefs that determine what people actually do when no procedure tells them what to do. In an organisation with healthy security basic assumptions, a developer who receives an unusual message from a LinkedIn contact pauses, because the unspoken norm is that unexpected contact from strangers deserves scrutiny. In an organisation with poor basic assumptions, the same developer opens the attachment, because the unspoken norm is that professional outreach is benign and only deliberately malicious things are threats.
Most security programmes intervene at Level 1 and sometimes at Level 2, then are surprised when Level 3 behaviour does not change. Changing basic assumptions requires consistent modelling by leadership over time, reinforcement through blameless incident review, visible consequences for security failures, and visible celebration of security successes. It is a leadership challenge, not a training design challenge.
5. Building Security Culture in a Small Web3 Team
The practical advantage of a small Web3 team is that culture change is faster than in a large enterprise. Leadership behaviour is visible to everyone. A single founder modelling the right behaviour has an organisation-wide effect. The following seven interventions, applied consistently, produce measurable change in a team of five to fifty people.
Leadership behaviour sets the tone
The most powerful cultural signal in any organisation is what leadership does, not what it says. If the CTO has hardware security keys on all accounts and refuses to approve a transaction that arrived through a single channel, every engineer in the firm receives a clear message about expected behaviour. If the founder bypasses the access approval process because they are in a hurry, every member of the team internalises the message that the process is optional under pressure. Culture flows downward from observed behaviour. Security4Web3's People, Process, Technology framework treats leadership behaviour as the first and most important cultural input, precisely because no technical control or process document can override it.
Specific behaviours for founders and CTOs to model:
- Always use hardware security keys; never use SMS-based two-factor authentication for privileged accounts
- Never approve a transaction or a system change that arrived through a single, unverified channel, regardless of time pressure
- Acknowledge and discuss security near-misses openly with the team rather than minimising them
- Complete all security training requirements, including simulated phishing exercises, alongside the rest of the team
- Publicly reinforce security decisions made correctly by other team members
Security in hiring
Hiring decisions are cultural decisions. Every person brought into the team either reinforces or dilutes its operating norms. Screening for security mindset, not just technical skills, is a requirement for building a strong security culture in a small team where individual attitudes have outsized influence.
Interview questions that surface security mindset include: "Tell me about a time you identified a security issue that wasn't your direct responsibility. What did you do?" and "If a trusted contact sent you an unsolicited file related to a project you're working on, what would you do before opening it?" Red flags include candidates who describe bypassing security controls as pragmatic problem-solving, who cannot articulate any personal operational security practices, or who treat security as someone else's function.
Hiring for technical roles also requires the specific vetting process for fake applicants: live unobscured video with location-specific questions, independent verification of prior employment, hardware shipment only to a verified address with access delayed until background checks are complete. North Korean operatives are systematically applying for roles at crypto firms. This is not a fringe risk. See the hiring security controls in our guide to Social Engineering Attacks Targeting Crypto Firms.
Security policies on day one
Onboarding is when cultural norms are established. A new team member who receives security policies on day one, who is walked through specific threat scenarios on day one, who meets their designated security escalation contact on day one, receives a clear signal about the organisation's priorities. A new team member who receives a link to the employee handbook in week three, with a note to complete the security training module when convenient, receives a different signal entirely.
Day-one security onboarding for a Web3 firm should cover: the specific social engineering threats the firm faces and the tactics that have been used against comparable organisations; the escalation path and contact for any suspicious interaction; the transaction verification procedure and why it is non-negotiable; hardware security key setup before any privileged system access is granted; and a walkthrough of the access controls that apply to the individual's role.
Phishing simulations
Regular phishing simulations are the most reliable behavioural measure available. They test whether training has produced actual behaviour change rather than test-passing. Critically, the purpose of a simulation is not to shame the people who click but to identify who needs additional support and to track whether the organisation's overall susceptibility is improving over time.
Web3-specific simulations should include the attack types the team actually faces: fake recruiter approaches on LinkedIn delivering coding challenges, spoofed Gnosis Safe or MetaMask notifications requesting credential entry, fabricated investor outreach requesting access to a demo environment. Generic phishing templates designed for corporate IT environments do not reflect the actual threat surface of a crypto team. The simulation programme should be designed around a specific threat model, not a generic awareness checklist.
Reporting rate matters as much as click rate. A team where 5% click but 80% report a suspicious simulation has a better security culture than one where 2% click and 10% report. The willingness to escalate is the behaviour that actually protects the organisation in a real incident.
Blameless incident reviews
The single most destructive thing a security leader can do after a near-miss is publicly assign blame to the individual involved. When a team member clicks a simulated phishing link and is publicly identified as the person who failed, every other team member learns to conceal the next near-miss rather than report it. The incentive structure is inverted. Blame produces hidden failures; psychological safety produces visible near-misses that can be addressed before they become incidents.
Blameless incident review, borrowed from the site reliability engineering discipline, treats every security failure as a system failure rather than a personal one. The question is not "who clicked the link" but "what in our environment made clicking that link the path of least resistance." This framing produces actionable improvements rather than individual embarrassment, and it produces a culture where near-misses are reported rather than concealed.
For the incident response framework that these reviews feed into, see our guide on building an Incident Response Plan for Crypto Organisations.
Security champions in each team
In organisations large enough to have distinct functional teams, a security champions programme places one individual per team, typically a developer or operations staff member, in the role of security advocate for their area. Champions are not security engineers. They do not own the security function. They are peers who have received additional training and who raise security considerations in their team's daily decisions.
The practical impact is significant. A security champion in the engineering team catches the PR that introduces a hardcoded private key before it is merged. One in operations flags an unusual vendor access request before it is approved. One in finance declines to process a payment that does not match the established verification procedure. This distributed responsibility model is particularly suited to Web3 firms, where security cannot realistically be owned by a single centralised function in a fast-moving, decentralised team structure.
Clear escalation paths
Every member of the team must know: who do I contact when something looks suspicious, and what happens when I do? In many Web3 firms, this question has no clear answer. There is no named security contact. There is no defined procedure for "I received a message that felt off." The absence of a clear escalation path means that every individual resolves their uncertainty alone, and individuals resolving uncertainty alone is precisely the condition that social engineering attacks are designed to exploit.
The escalation path should be simple, named, and tested. "If something looks suspicious, message [name] immediately on [channel]. No situation is too trivial to report. You will not be judged for raising a false alarm." This statement, modelled by leadership, repeated at onboarding, reinforced after every simulated phishing exercise, and tested in tabletop exercises, gradually becomes a basic assumption rather than a policy.
For the broader governance structure that formalises these escalation paths, including the vendor and third-party risk dimension that the Bybit case illustrates, see our framework for Vendor Risk Management in Web3.
Visible security wins
Organisations that only discuss security in the context of failures train their teams to associate security with bad news. Organisations that visibly celebrate security wins, the analyst who flagged a suspicious inbound transfer, the developer who identified a social engineering attempt before it progressed, the operations lead who enforced a verification step under time pressure, train their teams to associate security with professional pride.
This is not a trivial point. Recognition is a cultural signal. What gets recognised gets repeated. A regular channel, a weekly team meeting slot, or a shared document that records security catches and near-misses creates a positive feedback loop. It also provides ongoing evidence that the threat is real and the controls are working, which sustains motivation in a programme that may not have a dramatic incident to point to for months.
For the adversarial testing discipline that validates whether these cultural improvements are translating into genuine resilience, see our guide to Red Team and Blue Team Operations for Crypto Firms.
6. Measuring Security Culture
What does not get measured does not improve. Security culture programmes that run without measurement produce the impression of progress without the substance. The following metrics, tracked over rolling quarters, give a meaningful picture of cultural trajectory.
Phishing simulation click rate over time. A declining click rate is the most direct measure of whether security awareness training is producing behavioural change. The baseline for a new programme in a Web3 firm that has not previously run simulations will often be high. 20-30% first-time click rates are common in organisations with no prior simulation history. A well-run programme should reduce this to below 5% within 12 months. Stagnation or increase indicates that the programme is not landing.
Near-miss and suspicious activity report volume. Counterintuitively, an increase in near-miss reports is a positive cultural indicator, not a negative one. It means that people feel psychologically safe enough to report, and that they are recognising suspicious activity rather than dismissing it. An organisation with zero near-miss reports is not a safe organisation; it is one where people are not reporting what they see.
Policy acknowledgement and training completion rates. These are the lowest-quality metrics in the set, because completion of a training module does not indicate comprehension or behaviour change. They are necessary for compliance purposes and as a baseline input, but should not be confused with evidence of cultural health.
Time-to-escalation in simulated and real incidents. How long does it take from the moment a suspicious interaction occurs to the moment it is reported? In a strong security culture, escalation is instinctive and rapid. In a weak one, individuals sit on the information for hours or days, trying to decide whether it is worth reporting. This metric requires scenario exercises to measure reliably.
Staff security culture survey scores. A validated survey instrument, such as the Security Culture Survey developed by KnowBe4's research division, measures attitudes across seven dimensions: knowledge, behaviours, compliance, norms, attitudes, perceptions, and communication. Annual administration with quarterly pulse checks provides a longitudinal view of cultural direction that no single operational metric can replicate.
The access control dimension of this measurement programme is discussed in detail in our guide to Privileged Access Management for Crypto Firms, which covers the specific controls that limit the blast radius when cultural failures do occur.
7. From Compliance-Led to Values-Led Security
The distinction between compliance-led and values-led security culture is the difference between a team that passes audits and a team that survives attacks.
A compliance-led security culture produces people who complete mandatory training to get the completion certificate, acknowledge policies to clear the onboarding checklist, and apply security controls when they are being observed or when a process requires it. In this environment, security is understood as something the organisation does for regulators and auditors. The individual's personal stake in it is minimal. When an attacker presents a convincing scenario that bypasses the formal procedure, there is no internalised value that catches it.
"Compliance asks: did you follow the procedure? Security culture asks: did you do the right thing when the procedure didn't cover the situation? The second question is the one that determines outcomes in a real attack."
A values-led security culture produces people who apply security judgement in situations the procedures do not anticipate. They pause before an action that feels unusual, even when no policy explicitly requires them to. They escalate when they are uncertain, even when the path of least resistance is to proceed. They hold each other accountable for shortcuts, even when the shortcut is taken by someone senior to them.
The transition from compliance-led to values-led is a leadership project, not a training project. It requires leadership to model values-led behaviour consistently and visibly. It requires the removal of cultural incentives that reward speed over verification. It requires a blameless incident review culture that rewards honesty about failures. And it requires time: genuine cultural change in an organisation typically takes 12 to 24 months of sustained consistent effort before it becomes self-reinforcing.
The practical implication for Web3 security programmes is that the investment case for values-led security culture is not primarily the reduction in phishing simulation click rates. It is the reduction in the probability of a $1.4 billion loss caused by a team member who approved a transaction they should not have, because no one in the organisation had built the cultural reflex that would have made them stop.
Security4Web3's People, Process, Technology framework treats security culture as the foundational element of the People layer, because every other control in that layer, security awareness training, privileged access management, vendor risk management, incident response, degrades rapidly in a poor security culture and amplifies effectively in a strong one. The controls are multiplied, not merely added, by the culture in which they operate.
Frequently Asked Questions
What is security culture and why does it matter in Web3?
Security culture is the set of shared values, beliefs, and habitual behaviours that determine how an organisation's people think about and act on security when no one is watching. In Web3, it matters because technical controls degrade rapidly when the people operating them do not internalise security as a personal responsibility. A team that treats security as IT's problem will undermine multi-signature wallets, access controls, and audit trails through the same shortcuts that gave Lazarus Group its entry points.
Why do Web3 organisations have a poor security culture baseline?
Web3 teams combine a move-fast ethos with enormous concentrations of value, small headcounts with root-level access, pseudonymous collaboration, and a cultural suspicion of formal process. Developers routinely hold production keys. Founders bypass controls under deadline pressure. Security is treated as an obstacle to shipping, not a prerequisite for operating. This combination produces exactly the conditions that nation-state actors and organised criminal groups specifically target.
How does Lazarus Group exploit security culture gaps?
Lazarus Group's TraderTraitor unit targets organisations where security is perceived as IT's problem rather than everyone's responsibility. They look for developers who will open a file from a LinkedIn contact without escalating, for finance staff who will approve a transaction under time pressure, and for organisations where no one has a defined escalation path for suspicious interactions. The Bybit hack succeeded not because of a blockchain flaw but because human operators approved transactions they had not independently verified.
What are the three levels of security culture?
Drawing on Edgar Schein's organisational culture model, security culture operates at three levels. Artefacts are the visible elements: security policies, training modules, and access control lists. Espoused values are what leadership says: the CISO's presentations and the security section of the employee handbook. Basic assumptions are what people actually do when no one is watching: whether a developer pauses before opening an unsolicited attachment, whether a founder models waiting for out-of-band verification under pressure. Most organisations invest heavily in artefacts and say the right things at the espoused-values level while the basic assumptions remain unchanged.
How do you measure security culture in a Web3 team?
Useful metrics include phishing simulation click and report rates over rolling quarters, near-miss reporting volume (where more reports indicate psychological safety rather than more incidents), policy acknowledgement completion rates, time-to-escalation when staff encounter suspicious interactions, and periodic staff security surveys using a validated instrument such as the Security Culture Survey developed by KnowBe4's research division. Declining click rates and rising report rates together indicate a genuine culture shift rather than a compliance exercise.
What is the difference between compliance-led and values-led security culture?
Compliance-led security culture produces people who do the minimum required to pass an audit or complete a mandatory training module. Values-led security culture produces people who make security decisions instinctively, who escalate suspicious interactions without being asked, and who hold each other accountable for shortcuts. In a compliance-led culture, security policies are for auditors. In a values-led culture, they are operating norms that people follow because they understand why they exist. The difference is visible in the basic assumptions that govern behaviour when no procedure explicitly applies.