Cybersecurity for Startups: What Investors, Customers and the CRA Expect

Which rules apply to you

Fewer than you fear, but not none, and the ones that apply do not care how many people you are.

Cyber Resilience Act (EU) 2024/2847. Any product with digital elements placed on the EU market, from a hardware device to a downloadable app or on-premises software, must meet the essential requirements of Annex I and the manufacturer duties of Article 13. Reporting of actively exploited vulnerabilities under Article 14 applies from 11 September 2026, the full requirements including CE marking from 11 December 2027. Article 33 helps small companies with simplified documentation and guidance, nothing more. Pure SaaS is mostly outside, because it is not placed on the market.

RED delegated act (EU) 2022/30. If your product has a radio, which covers everything with Wi-Fi, Bluetooth or cellular, the cybersecurity requirements of the Radio Equipment Directive have applied since 1 August 2025. The EN 18031 series is the harmonised standard; without it or with its restricted parts you need a notified body.

GDPR. Article 32 requires security appropriate to the risk, including regular testing, and Article 33 gives you 72 hours to notify a personal data breach. For a startup with customer data this is the law most likely to be enforced against you first.

NIS2 indirectly. Under Article 2 most startups are below the size threshold. Your customers in regulated sectors are not, and Article 21(2)(d) obliges them to manage supply chain security, which is why their questionnaires arrive before the contract.

Investors do not cite articles. They ask for a pentest report in due diligence and price the absence of one into the valuation.

Where attackers start

A startup’s attack surface is its cloud account and whatever was built fastest.

• Cloud configuration: overly broad IAM roles, public storage buckets, databases reachable from the internet, secrets in environment variables of shared tooling.
• API authorisation: endpoints that check the user is logged in but not that the record belongs to them.
• Authentication: password reset flows, OAuth integrations, long-lived tokens embedded in mobile apps.
• Third-party services: the analytics, support and payment tools wired in with admin-level API keys.
• Hardware prototypes shipped as products: debug ports still open, flash unencrypted, one firmware key for every unit.
• People and offboarding: shared accounts, no multi-factor authentication on the deployment platform, former contractors still in the repository.

What assessments typically find

Typical findings from penetration tests of startup products, including ESP32-based devices, MQTT brokers, cloud APIs and apps, anonymised: an MQTT broker that accepted any client and allowed subscribing to every device’s topics, so one user could read every customer’s data; the same device certificate and key on every unit shipped, extracted in minutes through an open UART; an API that returned other users’ objects when the identifier was changed; a Firebase project with read access for unauthenticated clients; the backend’s JWT signing secret inside the Android app; an administrative dashboard protected only by an unguessable URL; and Wi-Fi provisioning over an open access point sending the home network password in plain text.

All of these were fixed within one sprint once found. None of them would have survived the first serious customer security review.

A sensible first project

Keep it small, fixed-price and useful for sales.

1. Scoping call and threat sketch: what the product is, what data it holds, who the customers are, what the next contract or round needs. Half a day, free.
2. Grey-box penetration test of the product core with test accounts: web application and API, cloud configuration, plus the mobile app or the device, firmware and radio where you ship hardware. One to two weeks.
3. Report in two layers: a fix list with reproduction steps for your engineers, and a two-page summary you can hand to customers and investors after the retest.
4. Retest and hardening plan: the fixed findings verified, and a short list of what to build in before the next milestone, for example signed firmware updates, per-device keys or a disclosure contact and security.txt.

Typical effort for steps 1 to 4 is 6 to 12 person-days, which is 7,000 to 20,000 euros at market rates. Plan it two months before the sales push or the data room, not two days.

What Zyberum does and does not do here

We test web applications, APIs, cloud environments, mobile apps and hardware, write a report you can show, help you set up the minimum process the CRA and your customers want, and answer security questionnaires with you. We are not a certification body and do not issue ISO 27001 or SOC 2 reports, we do not sell security products, and we do not provide a badge that stands in for an actual test. Every engagement starts with a free call and a fixed-price offer.