Cybersecurity for a New Product in 2026: The Controls to Build In From Day One

The cybersecurity trends people wrote about in 2021, such as remote access, cloud mistakes, phishing, ransomware and insiders, are now ordinary risks for any software product. For a new product, the useful response is a short list of controls in the first release and a clear list of what can wait. Most of the first list is about two things: who can see which data, and how the servers and cloud accounts are set up. Those are the first two risks in the current OWASP Top 10.

From trend lists to the OWASP Top 10:2025

The OWASP Top 10:2025 is the current edition of OWASP’s awareness list of the most critical security risks to web applications. Its ten categories are:

1. Broken Access Control
2. Security Misconfiguration
3. Software Supply Chain Failures
4. Cryptographic Failures
5. Injection
6. Insecure Design
7. Authentication Failures
8. Software or Data Integrity Failures
9. Security Logging and Alerting Failures
10. Mishandling of Exceptional Conditions

Several 2021 trends map straight onto it. Cloud mistakes are security misconfiguration. Insider risk is mostly access control: people seeing more than their job needs. Attacks through other people’s code show up as software supply chain failures. And the remote-work worries of 2021 come down to authentication and logging.

The latest breach data points the same way. Verizon’s 2026 Data Breach Investigations Report, which covers incidents from November 2024 to October 2025, says 31% of breaches now start with software vulnerabilities, ahead of stolen passwords, and 48% involve ransomware. Both call for two dull habits: update what you run, and keep backups you can restore.

The day-one controls

Control	What it means in practice	OWASP Top 10:2025	Where we did it
Access rules for every role, checked on the server	Each user sees only their own data, whatever the screen shows	A01 Broken Access Control	IPOPBOOKS: bookkeepers see only their own clients and never their contact details. Koncierge: each party sees only its own data
Sign-in from a provider, two-factor login for admins	Your app doesn’t invent its own login system	A07 Authentication Failures	Subflare: AWS Cognito. Sigmapool: two-factor authentication
Safe cloud setup	Private storage by default, only the ports you need, HTTPS everywhere	A02 Security Misconfiguration, A04 Cryptographic Failures	Sigmapool: HTTPS, SSH keys, Cloudflare protection
Secrets outside the code	Keys in a secrets manager, never in the repository	Covered in our guide to passwords and secrets	HealthyNikah: the old app had no safe place for keys
Dependencies pinned and updated	Known versions of every library, with updates on a schedule	A03 Software Supply Chain Failures	Ask for it in the scope
Input checked at the edge	Bad data stopped before it reaches business logic or the database	A05 Injection	Koncierge: broken payments stopped before the matching logic
A log of sensitive actions, with alerts to a person	Who did what and when, for money, permissions and data exports	A09 Security Logging and Alerting Failures	IPOPBOOKS: a log of every posted entry
Errors that fail safely	A crash or timeout never leaves a payment half done or shows internal details	A10 Mishandling of Exceptional Conditions	Ask for it in the scope

Backups an attacker can’t delete

Ransomware was on the 2021 trend lists, including the first version of this article, and it now shows up in nearly half of breaches. The answer for a product team hasn’t changed. Keep backups that someone with your production access can’t delete, and restore one before you need it. At least one copy should sit in a separate account or behind separate credentials. Sigmapool, a mining pool we built, goes further and keeps an active backup instance, so the platform can reset to a saved version in an emergency.

Make risky actions harder to fake

Some actions do the most damage when an attacker or a mistake triggers them: payouts, changes to an email address or password, new API keys, exports of customer data. Ask for a second confirmation on those. Sigmapool asks users to confirm actions by email, on top of two-factor authentication. Limit how many sign-in attempts one account can make in a short time, and tell users by email when their password or email address changes, so they notice a takeover early.

If your product keeps its own passwords, follow the current rules. NIST SP 800-63B-4, final since July 2025, asks for at least 15 characters when a password is the only factor and at least 8 with a second factor. It bans other composition rules, such as “one number and one symbol”, drops forced periodic changes and requires a check against a list of common or breached passwords. It also says passwords aren’t phishing-resistant, which is one more reason to use a sign-in provider and two-factor login.

Least access starts with your own team

Controls inside the app protect you from outsiders. Your developers, your agency and your contractors need limits too. During the IPOPBOOKS build, only one person at Rocketech could see client data. Give the team a copy of production with test data, and keep production access for the few people who need it, through named accounts with two-factor login. Remove a contractor’s access on the day their work ends, and change any shared password they could see.

Privacy basics cost little on day one

Some privacy features are cheap to build at the start and expensive to add later. Subflare, a lead scoring product for EU businesses, had them from day one: no passwords to handle, logged consent, a way for clients and leads to delete their own data, and all data stored on AWS in Europe. The Subflare case study shows how they fit into the first release.

Partners will ask for proof

IPOPBOOKS, a bookkeeping platform we built for US small businesses, is a good example. The founder was clear from the start that quality and data security came before speed. The launch moved from June 1 to June 16 so the team could test everything with live bank data. And the first US bank data provider asked for a stack of security policies before it would sign, so we moved the bank feeds to another provider to keep the launch on time.

Banks, payment providers and larger customers will ask how you protect data. Write the answers down while you build: the access rules, where data lives, who can reach production, how you back it up and how you respond to an incident. Our incident response runbook covers the last one.

Regulators now set dates too. The EU’s Cyber Resilience Act covers hardware and software products with digital elements. Since 11 September 2026, manufacturers have had to report actively exploited vulnerabilities, and the main obligations apply from 11 December 2027. If you sell software or connected devices in the EU, ask a lawyer whether your product is in scope.

What can wait

Not everything belongs in a first release. These usually come later, once real users and real money are on the platform:

• A penetration test by an outside firm, before you onboard a large customer or hold sensitive data at scale.
• Formal certifications, when your buyers start asking for them.
• A full check against the OWASP Application Security Verification Standard (ASVS 5.0.0, released in May 2025), which turns security into testable requirements.
• A written secure development process. NIST’s Secure Software Development Framework (SP 800-218) lists practices that fit into any development process.

Even before a full check, use the ASVS as a reference when you write acceptance criteria.

How we would estimate your security work

Security work is easiest to fund when it sits in the first budget. You can estimate your MVP’s cost and timeline with our project estimate. It works in four steps:

1. Your brief becomes user stories, and each control in the day-one table can be one of them: role rules, the sign-in provider, the secrets manager, the action log and safe error handling. You confirm what is in scope, so you see what security adds to the budget, and every hour traces back to a story you kept.
2. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. It’s a planning range, not a fixed quote.
3. For market size, the estimate suggests customer groups and gives each a TAM, SAM and SOM with a note on what the number covers. Treat them as hypotheses to test, not verified demand. Keep only the groups you would really sell to, and the market and unit economics are worked out only for those.
4. The unit economics show how many customers pay for the build and in which month it is paid back. You can change any starting number and the math updates.

What we would do

1. Write a table of roles and what each role may see and do, before anyone designs a screen.
2. Use a sign-in provider and turn on two-factor login for every admin.
3. Keep every secret in a secrets manager from the first commit.
4. Log every action that touches money, permissions or exports, and send alerts to a named person.
5. Turn on automatic dependency updates and review them every week.
6. Give your own team and contractors the least access their work needs.
7. Write down how you protect data, before a partner asks for it.

These controls fit into a normal first release. A first version with us typically costs $5,000 to $15,000 and takes 2 to 4 weeks; see our MVP development page for what is included. If the product already exists and you don’t know how safe it is, our code audit costs a fixed $3,500, takes 5 working days and ranks the security problems it finds with the worst first.

FAQ

What security does an MVP need?

Access rules checked on the server, sign-in from a provider with two-factor login for admins, a safe cloud setup with HTTPS, secrets kept out of the code, updated dependencies, input checks and a log of sensitive actions. A penetration test and formal certifications can usually wait until real users and real money arrive.

What is the OWASP Top 10:2025?

The current edition of OWASP’s list of the most critical security risks to web applications. Its ten categories start with Broken Access Control and Security Misconfiguration, followed by Software Supply Chain Failures, Cryptographic Failures and Injection.

Do we need a penetration test before launch?

Not always for a first release with test users. Plan one before you onboard a large customer, take payments at scale or hold sensitive personal data. Our code audit reviews code and setup but doesn’t include penetration tests.

How do I check the security of an app another team built?

Start with an audit of the code and the accounts. Ours costs a fixed $3,500, takes 5 working days and lists every account the product depends on and whose name it is in, with the security problems ranked worst first.