There is a problem that the cybersecurity industry does not talk about enough, largely because fixing it is not in the immediate financial interest of most of the companies that could fix it.
The tools that genuinely protect data are, in most cases, too technically demanding for the average person to use correctly. Configuration files. Key management. Protocol selection. Certificate handling. These are not concepts that most people have any reason to understand, and yet getting them wrong is the difference between data that is protected and data that is not. On the other side of that equation sit the tools that are easy to use. Intuitive interfaces, one-click setup, consumer-grade simplicity. They are accessible to everyone. They also, in most cases, do not provide adequate protection. They encrypt in transit but not at rest. They have permissive defaults. They rely on password authentication that has been shown, repeatedly, to be insufficient. They prioritize convenience over control because that is what drives adoption, and adoption is what drives revenue.
This is not a coincidence. It is a design choice.
88% of cybersecurity breaches are caused by human error, according to a study by Stanford University and security firm Tessian. That figure is cited so often it has become background noise, but it deserves more scrutiny than it usually gets. The Verizon 2024 Data Breach Investigations Report, which analyzed over 30,000 security incidents and 10,626 confirmed breaches, puts a related figure at 68% of breaches involving a non-malicious human element, whether through error or social engineering. Across multiple independent sources, the picture is consistent: people are the most exploited variable in the security equation, not because they are careless, but because the systems they use have been built in ways that make mistakes easy and correct behavior hard.
The question these numbers raise is not "why do people keep making mistakes?" It is "why have we built systems where the correct behavior is so technically demanding that error rates approach 90%?"
Over 560 million Ticketmaster customers had their data exposed in a 2024 breach traced back to a single cloud account protected only by a password. The attackers used stolen credentials obtained through info-stealer malware, and the absence of multi-factor authentication meant there was nothing left to stop them. According to Microsoft's own research across hundreds of millions of accounts, MFA blocks over 99.9% of automated account takeover attempts. It was not in place because nobody had made it the default, and most users had no particular reason to know they needed it.
That is the gap. Not technical ignorance on the part of users. A systemic failure to make the secure option the easy option.
There is a dimension to this that support data makes impossible to ignore, and that almost nobody in the industry discusses openly.
Three quarters of CISOs identify human error as their most significant cybersecurity vulnerability, according to Proofpoint's 2024 Voice of the CISO Report, which surveyed 1,600 chief information security officers across organizations of 1,000 employees or more. What that figure does not capture is where a meaningful portion of that human error actually originates. It is not only end users clicking phishing links. A significant share lives inside the teams responsible for configuring and operating security infrastructure.
It is not unusual to receive a foundational security question, something unrelated to any specific product and rooted entirely in basic concepts, from someone whose job title carries the word Senior. This is not a criticism of those individuals. It is a symptom of an industry that has created strong incentives to project expertise and very few safe spaces to admit gaps. The result is a specific and underreported failure mode: someone with authority over a security configuration does not fully understand what they are configuring, does not ask because asking feels professionally risky, proceeds anyway, and the configuration is wrong in ways that remain invisible until an incident occurs.
The 88% human error figure is not just about users clicking phishing links. A meaningful portion of it lives in the gap between stated expertise and actual understanding. Training is part of the answer, but it is not sufficient on its own. The more durable solution is software that makes the correct configuration the only easily available one. A platform that enforces secure defaults rather than offering them as options does not depend on every administrator having fully internalized the threat model. It closes the gap structurally, not through education alone.
This is where it gets uncomfortable, because the honest answer is that the market, left to its own devices, will not close it.
Building security that is both genuinely effective and accessible to non-technical users is expensive. It requires sustained investment in interface design, sensible defaults, and the kind of opinionated engineering that hides complexity without sacrificing the underlying rigor. That work does not produce features that show up in a marketing comparison table. It produces an absence of incidents, which is invisible until something goes wrong. Companies that make that investment are competing against companies that spend the same resources on features that are easier to demonstrate and easier to sell.
The businesses that are genuinely committed to solving this problem, not just in the language of their mission statements but in their actual product decisions, enforce MFA by default rather than offering it as an opt-in. They make secure configuration the path of least resistance rather than a reward for technical sophistication. They accept that a more opinionated product is sometimes a harder sell, and make that trade anyway. Those companies exist. They are not the majority.
The alternative is to treat this as a regulatory problem. Governments in several jurisdictions are moving in this direction. GDPR created legal liability for organizations that fail to protect personal data. HIPAA mandates specific controls for healthcare data. The EU Cyber Resilience Act introduces security-by-design requirements for connected products at the design level, meaning security can no longer be bolted on after the fact. These frameworks are imperfect and often lag behind the actual threat landscape by years, but they represent an acknowledgment that market incentives alone are not sufficient to produce secure-by-default products.
File transfer is one of the most routine and least scrutinized parts of most organizations' data flows. Data moves between systems, between organizations, and between users constantly. That movement is where sensitive information is most exposed, and it is frequently the last place anyone looks when evaluating security posture.
The same design failure plays out in file transfer infrastructure constantly. Legacy protocols with known weaknesses remain in use because replacing them requires effort and expertise. Shared credentials persist because setting up individual accounts with granular access controls is more work. Audit logging is enabled but never reviewed because the volume is unmanageable without tooling to surface anomalies. MFA is available but not enforced because enforcing it creates friction for users who push back.
The file transfer platforms that take the design problem seriously make these decisions for the administrator rather than leaving them as options. Encryption is not a setting to be enabled. It is the only mode. MFA is not a recommendation. It is a requirement. Access controls are not a configuration task to be completed later. They are the default structure the system is built around. The question worth asking of any file transfer platform is not what it is capable of in the hands of an expert. It is what it does when configured by someone under time pressure who may not fully understand the implications of each setting.
The answer to that question is where the real security posture of an organization gets determined. Not in policy documents. Not in compliance attestations. In the defaults.
Individuals are responsible for their own security in the same way that drivers are responsible for road safety. Technically true. Also insufficient as a complete picture.
People make decisions within systems they did not design, using tools they did not choose, in an environment shaped almost entirely by organizations whose financial incentives do not naturally align with the user's security interests. Expecting individuals to compensate for structural failures they had no part in creating is not a security strategy. It is a way of distributing blame after the fact.
The distribution of responsibility is real, but it is not equal. Software companies bear the largest share. They decide whether MFA is on by default or buried in settings. They decide whether secure configuration is the path of least resistance or a reward for technical persistence. They decide whether the product ships with sensible defaults or with defaults optimized for a smooth onboarding flow that leaves users exposed. Those are engineering decisions, made by people with full knowledge of the consequences.
Governments set the floor. Regulatory frameworks like GDPR and the EU Cyber Resilience Act are a recognition that the market will not raise that floor on its own. Individuals bear a real share too, but it is the smallest of the three.
The companies that take this seriously do not wait for regulation to force the issue. They build secure-by-default products because they understand that accessibility and protection are not opposing values, and because they have decided the investment is worth making regardless of whether it shows up in a feature comparison. That is an engineering choice. It is also an ethical one. The data breach statistics are, in part, the receipt for the companies that made the other choice.
