Security-by-design is the right principle, and being right is not the same as working. Across large enterprises, the principle reliably breaks in three specific places, and they are places no framework diagram shows.
The frameworks describe an ideal: security built in from the start, owned by the teams that build, tested continuously, never bolted on at the end. The ideal is correct. What the frameworks do not describe is where the ideal collides with how large development organisations actually work, and that collision happens at three predictable points. Naming them precisely matters, because each failure has a specific process redesign that fixes it, and treating security-by-design as a single cultural aspiration rather than three concrete process problems is why so many programmes stall with the principle accepted and the practice unchanged.
Failure One: Requirements Defined Too Late to Shape Architecture
The first failure is timing. Security requirements get defined late in the delivery cycle, after the architecture is already set, which means they cannot influence the decisions that most determine security. By the time security looks at the design, the framework is chosen, the data flows are fixed, and the boundaries are drawn. Security is left to add controls around an architecture it had no hand in shaping, which is the most expensive and least effective point at which to involve it.
The redesign is to move security requirements into the moment of architectural decision, not after it. That means defining security requirements alongside the functional ones, during design, when changing the architecture is still cheap. In practice it is a threat-modelling step at design time and a security voice in architecture review, so the requirements arrive while they can still change the shape of the system rather than just decorate it. The shift is small in process terms and large in effect, because it moves security from reacting to an architecture to helping form one.
Failure Two: Testing Treated as a Gate, Not a Feedback Loop
The second failure is the role of testing. Security testing is treated as a quality gate, a checkpoint near the end that a release must pass, rather than as a feedback loop that informs development as it happens. As a gate, security testing finds problems late, when they are expensive to fix and politically charged to raise, and it pits security against the deadline. Developers experience it as an obstacle, security experiences delivery as reckless, and the relationship sours exactly where it needs to be collaborative.
The redesign is to turn the gate into a loop. Security testing runs continuously and in the developer’s workflow, so findings arrive while the code is being written, in the same place and at the same speed as any other test result. A vulnerability surfaced in the pull request, with the context fresh, is a quick fix and a learning moment. The same vulnerability surfaced at a release gate weeks later is a crisis. Same test, same finding, completely different cost and tone, and the difference is entirely whether testing is positioned as feedback during development or as judgment at the end.
Failure Three: Ownership That Never Leaves the Security Team
The third failure is ownership, and it is the deepest. In most enterprises, security ownership stays with the security team even after a programme has declared that security has shifted to the developers. The developers are told they own security; the security team still makes the decisions, holds the accountability, and runs the controls. Nothing actually moved, and the developers know it, so they treat security as the security team’s job, because in every way that matters it still is.
The redesign is to move ownership for real, which is harder than any tooling change because it redistributes authority. The delivery team has to own the security decisions for its own service, with the security team shifting from making those decisions to enabling them, providing expertise, tooling, and guardrails rather than approvals. This only works if the delivery team is measured on security outcomes and equipped with the capability to handle them, which means the ownership shift comes with both accountability and investment. Declare the shift without those two, and ownership stays exactly where it was, whatever the org chart now says.
Three Failures, Three Redesigns
What unites the three failures is that each is a specific, fixable process problem masquerading as a cultural one. Programmes that treat security-by-design as a mindset to be adopted exhort everyone to care more and change nothing concrete. Programmes that treat it as three process problems move the requirements earlier, turn the testing gate into a feedback loop, and shift ownership for real with the accountability and capability to make it stick. The first approach produces posters. The second produces security that is actually built in, because it changed the processes where the principle was breaking rather than restating the principle louder.
Where Security-by-Design Actually Breaks
Security-by-design fails in practice not because the principle is wrong but because organisations adopt it as an aspiration instead of fixing the three places it predictably breaks. Requirements arrive too late to shape the architecture; testing is positioned as a gate instead of a feedback loop; and ownership is declared to have moved while staying exactly where it was. Each has a precise process redesign, and none of them is a tool. Find these three failure points in your own delivery, apply the specific fix to each, and security-by-design becomes an operational reality. Leave them in place, and it stays what it is in most enterprises: a principle everyone endorses and no process actually enforces.