01
Security Architecture
Start with the assumptions that would hurt most if they were wrong.
- Tenant isolation and authorisation requirements
- Trust boundaries engineers can use
Outcome
Engineers know what the product must preserve.
Product security for B2B software
Keep the security properties of your B2B product working as larger customers arrive
I help B2B software teams answer detailed customer security reviews, then make sure those answers remain true after the next release.
Worked with engineering teams at
Larger customers ask for specifics
Early on, security knowledge is usually close to the people building the product. A senior engineer knows the dangerous edges, the CTO reviews sensitive changes, and a periodic test catches what the team missed.
That stops being enough when a B2B software company starts selling to larger or regulated customers.
The questions become specific: how is tenant isolation enforced? Who can approve a sensitive action? What happens when a vulnerability is found? ISO 27001, SOC 2, and an annual pentest may all be in place, but they do not answer the question a buyer is really asking:
Can you show that the parts of the product your customers depend on still work securely after the next release?
At that point, security decisions need to be written down, assigned to someone, and checked again when the product changes.
A completed ticket is not proof
You may already have ISO 27001, pentest reports, scanners, security tickets, and useful findings from external assessors. Those show that security work is happening. They do not tell you whether the product is getting safer release by release.
This is common in B2B software. The AppSec function is small, or does not exist yet. Findings arrive faster than engineering can triage them properly, and the context behind an old decision is often sitting with one person.
The risk is not just the vulnerability that is still open. It is having no dependable way to decide what matters, define a fix, and check that the fix worked.
The symptoms are easy to recognise: findings without a clear owner, closed tickets that do not show what was checked, and the same vulnerability class returning after a few releases. Then a customer review arrives and the team has to reconstruct the answer from scattered tickets, reports, and memory.
What I help teams put in place
The work includes application and API security, secure delivery, remediation, and testing fixes after they ship. The useful question is what your team needs to do differently in the next release. Learn how it all fits together.
02
Security Engineering
Turn a finding into work someone can own, ship, and revisit.
- A remediation workflow with clear ownership
- Controls in code and delivery
Outcome
Security work has a place in the product backlog.
03
Continuous Assurance
After a fix ships, check that it survived the next change.
- Verification for important fixes
- Evidence of regressions being caught
Outcome
Customer answers are backed by current evidence.
What changes after the assessment
A cleaner report is useful. The important part is knowing what the product must protect and being able to show that those protections still work.
People know what cannot break
Tenant isolation, authorisation, sensitive data flows, and other important product behaviour are written down clearly enough to design and test.
Findings have an owner and a test
The team decides what matters, assigns the work, and checks the result instead of treating a closed ticket as proof.
Customer answers come with evidence
When a buyer asks how a control works, the answer comes from the product and its process, not from a rushed search for an old report.
"Søren quickly grasped the technical and business context of our project and added value from day one. His strong engineering background and structured thinking made collaboration seamless."
René Passmann
CEO, HAV Media
Product Security Assessment
1 week · €3,500 fixed fee
We look at how security decisions are made today: what the product is meant to protect, how findings reach engineering, and what happens after a fix is merged.
The assessment shows how security work actually moves through the product and the team today. It identifies the few gaps that create the most risk or customer friction, rather than producing a long list of theoretical improvements.
You leave with a prioritised plan and a clearer answer to what deserves investment next. If deeper work makes sense, I scope a fixed-price engagement around that work. If it does not, the assessment still stands on its own.
Søren Johanson
Product Security Consultant
I am an independent Product Security consultant working with European B2B software vendors. Over more than ten years I have built and reviewed software for enterprise and public-sector customers, from multi-tenant platforms serving millions of users to the identity systems they rely on.
I work with engineering teams that need to explain and improve the security decisions behind their product, especially as larger customers start asking more detailed questions. I write security requirements engineers can design against, model where a product can fail, audit authentication and authorisation, and help teams turn findings into fixes they can verify.
I have also trained engineering teams on API security and threat modelling, and I build and sell my own security product. RecoveryCodes is a B2B SaaS tool that maps the MFA-protected accounts an identity provider does not see, so teams know which authenticator or recovery code protects each one. Running it keeps me on the vendor’s side of the table, where security has to hold up for customers, not only for an auditor.
Notes from product security work
2026-09-02
AI doesn't eliminate the cost of owning software
I'm deep into reading papers about AI, mostly with regard to secure code generation and trust in AI models. Compared with the enormous amount of dfiscussion around AI...
Read more2026-09-01
AI still doesn't consider security proactively
AI has improved substantially over the last few years, and AI coding agents are now widely used. They play a significant role in all of my recent projects, from the Weekplanner...
Read more2025-07-30
Your legacy API isn't the problem. Your documentation is.
For many mid-sized companies, an API exists somewhere in the system. It might have started years ago as an internal tool. Maybe it was built quickly to satisfy a one-off partner...
Read more