What security work does a startup need before launch?

A startup security checklist before launch comes down to five essentials: multi-factor authentication (MFA) and individual logins, server-side access checks, a scan for secrets across the full repository history, an inventory of third-party access, and patched dependencies. You also need one security alert that reaches a real person. Exploitation of known vulnerabilities is now the most common starting point for breaches. Penetration tests (pentests) and SOC 2 can come later, when a buyer requires them.

Key takeaways

• Exploitation of known vulnerabilities is the most common starting point for breaches, accounting for 31% of breaches in Verizon's 2026 Data Breach Investigations Report and 32% of intrusions in Mandiant's M-Trends 2026.
• Third parties are involved in roughly a third to half of breaches. Verizon's 2026 DBIR puts the figure at 48%, while SecurityScorecard's analysis of 1,000 breaches found third-party involvement in 35.5%.
• Broken access control ranks first in the OWASP Top 10 for 2025. It appeared in some form in 100% of the applications tested, while Missing Authorization ranks fourth in MITRE's 2025 CWE Top 25.
• Leaked secrets can remain valid for years. More than 64% of secrets confirmed valid in 2022 were still valid in January 2026, and Truffle Security found that working credentials exposed on public GitHub had a median exposure period of 784 days.
• MFA reduced the risk of account compromise by 99.22% in a Microsoft study of Azure Active Directory accounts. Where passwords had already leaked, the reduction was 98.56%.
• Denmark's national register lost data on approximately 8.8 million people through a small company's legitimate access. The breach was detected after an unusually large invoice.

In this article

• How do small companies get breached?
• What should you do before launch, at seed, and before Series A?
• What belongs on a startup security checklist before launch, in order?
• When are a pentest and SOC 2 worth paying for?
• Where RocketDevs fits
• Conclusion: close the five security gaps before you scale
• Frequently asked questions

How do small companies get breached?

Most breaches start through a handful of common entry points. The most common first step is exploiting software with a known vulnerability that nobody has patched. Exploitation accounted for 31% of breaches in Verizon's 2026 Data Breach Investigations Report. Mandiant's M-Trends 2026 report also ranked exploits first for the sixth consecutive year, accounting for 32% of intrusions.

Most pre-launch security checklists in search results contain twenty or thirty items, often presented as equally important. A seed-stage startup with two engineers cannot tackle everything at once. The breach data suggests a more practical approach: prioritise the risks that are most likely to matter.

Verizon's full 2026 DBIR covers more than 31,000 incidents, including over 22,000 confirmed breaches, recorded between November 2024 and October 2025. Its small-business analysis covers organisations with fewer than 1,000 employees, a category much broader than seed-stage startups. Among the 7,152 breaches in that group, exploitation accounted for 26% of initial access, credential abuse for 13%, and phishing for 9%. A third party was involved in 55% of breaches.

Neither report isolates pre-revenue startups, so these figures indicate the general pattern of risk rather than the exact odds facing a new company. Both datasets point to the same priorities: patch vulnerable software, control who can access your systems, and manage the suppliers that hold your credentials or data. Add the access-control weakness found across web applications, and you have five main entry points to address.

Software with a known hole

One of the most important security tasks is also one of the easiest to overlook: patching known vulnerabilities. The CISA Known Exploited Vulnerabilities catalogue contained 1,739 vulnerabilities in its 8 October 2026 release, all confirmed as exploited in the wild. Of those, 255 had been added during 2026 alone.

These attacks are not limited to large enterprises. Verizon's DBIR found that ransomware victims were typically compromised through compromised credentials (38%) or unpatched vulnerabilities in edge devices (29%). Approximately 96% of ransomware victims whose organisation size was known were small or medium-sized businesses.

A startup running on a managed cloud platform has fewer edge devices to worry about than a factory. It still depends on software libraries, base images and services that may have been exposed to the internet to get a demonstration working.

The pre-launch response is straightforward. Enable automated dependency-update pull requests, prioritise security fixes, and keep an inventory of services listening on public ports. The UK's Cyber Essentials scheme is built around five security controls, including security update management, designed to protect against common internet-based threats.

Credentials nobody owns

Credentials are no longer the most common initial entry point, but they remain the most common attack vector across breaches as a whole. In the 2026 DBIR, credential abuse fell from 22% to 13% of initial access, partly because the report now tracks pretexting separately. Credentials still appeared somewhere in 39% of breaches, more than any other vector.

Once an attacker gains access through a software vulnerability, credentials may provide a way to move further into the system. Shared passwords and accounts that nobody remembers to disable make that easier.

Multi-factor authentication (MFA) is one of the most effective and accessible controls available. A Microsoft study of Azure Active Directory accounts found that MFA reduced the risk of account compromise by 99.22% across the studied population and by 98.56% where credentials had already leaked. These figures come from Microsoft's own identity product, so that context matters. The US Cybersecurity and Infrastructure Security Agency (CISA) also recommends MFA and identifies phishing-resistant methods as the preferred standard. These include FIDO and WebAuthn passkeys or security keys. See CISA's MFA guidance.

Account ownership is equally important. Give every person an individual account so that access can be revoked without changing a password shared across the team. Remove default passwords before launch. CISA lists default credentials, hardcoded credentials and administrator accounts without MFA by default among its product security bad practices.

Password policies should follow NIST SP 800-63B. The standard requires checking new passwords against a blocklist of commonly used or compromised passwords and says services must not force periodic password changes, only a change when there is evidence of compromise. Assign responsibility for offboarding, too, so a departing employee or contractor loses access on their last day rather than whenever someone remembers to remove the account.

The server that trusts the browser

Broken access control occurs when an application fails to enforce what a user is allowed to see or do. For example, a user changes an ID in a request and gains access to another customer's invoice, profile or file.

The OWASP Top 10 for 2025 ranks broken access control first. It appeared in some form in 100% of the applications tested, across 1,839,701 recorded occurrences. MITRE's independent 2025 CWE Top 25 reinforces the concern: Missing Authorization ranks fourth, up five places, while Incorrect Authorization ranks 17th and Authorization Bypass Through User-Controlled Key ranks 24th.

Although this weakness is not among the leading initial entry points in the breach datasets, it deserves attention because of the potential damage. A single missing check in an endpoint that returns customer records could expose information belonging to many users. An attacker may need nothing more than an ordinary account of their own.

OWASP's example shows how an attacker can change an account parameter in a browser request to access another account. The principle is simple: access control must be enforced by trusted server-side code. Hiding a button, disabling a field or restricting a front-end route may improve the user experience, but none of these measures prevents someone from sending a modified request directly to the server.

Testing this before launch can take an afternoon. Create two accounts belonging to different organisations. Perform actions as user A, then replay the requests using user B's session and user A's resource IDs. If the server returns data that user B should not see instead of rejecting the request, investigate the access-control failure. Add the test to the automated test suite so future changes cannot quietly reintroduce the same weakness.

Secrets that never leave the history

A secret is a credential, such as an API key, access token or password, used by an application or service. If someone commits a secret to a repository, deleting the file does not remove it from the repository's history. Copies may also remain in clones and forks created before the exposure was discovered.

GitHub's documentation on removing sensitive data recommends revoking or rotating exposed secrets first. It also warns that copies of a commit may remain accessible in forks even after repository history has been rewritten.

The scale of the problem is substantial, and exposed credentials can remain usable for years. GitGuardian counted 28.65 million new hardcoded secrets added to public GitHub commits in 2025 in its State of Secrets Sprawl 2026 report. When it retested secrets confirmed valid in 2022, more than 64% were still valid in January 2026.

Truffle Security reported that it had scanned 224 million public repositories and found 543,699 credentials that still authenticated when it tested them in July 2026. Its research found a median exposure period of 784 days for those working credentials. GitHub separately reported that more than 39 million secrets were leaked across its platform in 2024 in its GitHub Advanced Security announcement.

These companies sell secret-scanning or secret-protection products, so their commercial interests are worth considering when evaluating their findings. However, the problem predates these products. Peer-reviewed research by Meli, McNiece and Reaves in 2019 found secret leakage across more than 100,000 repositories, with thousands of new secrets appearing daily.

The order of remediation matters. Deleting a line of code does not invalidate the key it contained. Scan the complete repository history, rotate every live secret you discover, and then clean the history where necessary. Open-source tools can help: gitleaks and TruffleHog are two of the most-starred open-source secret scanners on GitHub, with 29,843 and 28,419 stars respectively on 11 October 2026.

Somebody else with a login to your data

Every vendor, contractor and integration with credentials to your systems creates another potential route into your environment. Verizon found third-party involvement in 48% of breaches in its 2026 DBIR, up from 30% the previous year. SecurityScorecard, using a different definition of third-party involvement, found that 35.5% of breaches in 2024 were third-party-related, per its 2025 Global Third-Party Breach Report. The figures are not directly interchangeable, but both show that suppliers can introduce significant risk.

Third parties may also take a long time to fix weaknesses. A DBIR dataset covering third-party cloud environments found that only 23% of third-party organisations fully remediated missing or misconfigured MFA on their cloud accounts. Weak passwords and permission misconfigurations took almost eight months before half of them were resolved.

Mandiant describes a related attack pattern in M-Trends 2026: attackers compromise a software-as-a-service (SaaS) vendor, obtain hardcoded keys or personal access tokens, and use those credentials to target the vendor's customers.

Small companies often have limited visibility into these relationships. The UK's Cyber Security Breaches Survey 2025/2026, which surveyed 2,112 businesses, found that only 15% had reviewed the risks posed by their immediate suppliers and 6% had reviewed risks across their wider supply chain.

For a startup, third-party access might come from a contractor's laptop, an analytics script, a continuous integration service with deployment keys or an AI tool that can access the repository. Create a written inventory of every third party with access. Record what each can reach, which account or credential it uses, and who is responsible for revoking access. Our contractor offboarding access checklist covers the people side of this process in more detail.

The Danish register: several doors in one week

A Danish data breach reported in October 2026 illustrates how legitimate access can become a route to large-scale data exposure.

On 5 October, Denmark's CPR office announced that unauthorised parties had obtained names, addresses and CPR numbers belonging to approximately 8.8 million registered people. The incident involved misuse of a Danish company's lawful access to the national register. According to Ritzau, the register holds records for around 11 million people, including emigrants and deceased individuals. Pays ApS, a small IT company in Odense, confirmed to TV 2 that its access had been misused.

The precise route of access remains uncertain. The attacker told TV 2 that a former employee's password had been used, but neither the company nor the authorities had confirmed that claim. Politiken reported, based on data it said the attacker had used, that at least three company accounts, including the administrator account, used the password 123456. That detail rests on a single newspaper's reporting. The password is nevertheless a well-established example of a weak credential: in 2019, the UK's National Cyber Security Centre found it on 23.2 million breached accounts.

The timeline is also inconsistent across the available reports. The Danish ministry said the CPR administration noticed irregular activity on the evening of Friday 2 October, relating to activity during September. According to TV 2's account of the CPR office's report to the Danish Data Protection Agency, the company's access was closed on 2 October, early findings suggested the unauthorised access stopped on 20 September, and the report recorded a total access period of 21 days and 17 hours from 10 September. These details do not consistently describe the same period. One possible interpretation is that the credential remained valid after the data extraction stopped, but this has not been confirmed.

The discovery mechanism is clearer. A CPR employee noticed an unusually large invoice to the company. The firm had conducted approximately 14 million searches against the register, far more than its customer base could explain, according to TV 2's reporting on the investigation and Ritzau's coverage.

After the incident, the CPR administration contacted 1,039 companies with register access, including banks and unions, to remind them of their security obligations. The scale of that response shows how many organisations may hold legitimate access to sensitive data. Public attention also grew quickly: the Hacker News discussion of the announcement received 509 points and 352 comments, while views of the Danish Wikipedia article on CPR numbers rose from 9 on 4 October to 493 on 5 October.

The incident illustrates several of the risks in this checklist. A small company had privileged access to another organisation's sensitive data. Reports raised questions about account ownership and weak passwords. The available evidence does not establish whether MFA was absent, so it would be wrong to state that the company definitely lacked it. What is clear is that the excessive activity was detected through an unusually large invoice rather than an earlier security alert.

The alert that reached nobody

Detection is the sixth item on the checklist because it does not prevent an attack. It limits how long an attacker can operate before somebody responds.

In the investigations covered by Mandiant's M-Trends 2026, organisations detected attackers themselves 52% of the time, up from 43%. Median dwell time, the period an attacker remains in an environment before detection, rose to 14 days. In the remaining cases, someone outside the organisation alerted the victim.

A seed-stage startup does not need a security operations centre. It needs an alert for unusual activity that reaches a named person who is responsible for responding.

Cloud billing alerts are a useful starting point. The Danish case shows how an unusual bill can expose activity that otherwise goes unnoticed. AWS Cost Anomaly Detection, for example, uses machine learning to identify unusual spending patterns. It runs approximately three times a day and may take up to 24 hours to detect an anomaly, so it should not be treated as an immediate security alert.

Add a second alert for activity within your own product. Track how many records each account reads or exports per hour and compare that activity with its usual pattern. A sudden spike should trigger a notification to someone who can investigate.

A company should not discover that an account has run 14 million searches when the invoice arrives.

What should you do before launch, at seed, and before Series A?

Before launch, close the five doors and wire one alert, which is mostly engineering time. At seed, make those habits survive new hires and new vendors. Before Series A, or whenever a named buyer asks, buy the external evidence: a pentest, and a SOC 2 report if your customers' procurement demands one.

The order follows the breach data rather than the checklist. The controls that stop the common first steps cost little, and the reports that prove them to someone else cost a lot, so the reports wait until someone is asking for them. If you sell into health, finance or government, that someone may arrive with your first customer, and the right column below moves left.

The stage that gets skipped is the second row. A founder who has done the five-door work can answer most of a first security questionnaire honestly in an afternoon. A founder who has not will either stall the deal or write answers that are not true, and the second is worse than the first. Our guide to what technical due diligence checks at Series A covers what an investor looks at in the last row.

What belongs on a startup security checklist before launch, in order?

Six steps help a startup reduce its biggest security risks before launch: secure user accounts, test access permissions, scan for exposed credentials, review third-party access, apply security updates and configure alerts, and test backup recovery. A small team can aim to complete all six in a week of focused work.

Step 1: secure accounts and require MFA

Give every employee and contractor an individual account through a central identity provider. Require MFA for that provider, your cloud management console and your code hosting platform. Remove default passwords from anything you deploy.

For Amazon Web Services (AWS), MFA is required for the root user across account types. AWS also recommends passkeys or security keys. See the AWS guide to enabling MFA for the root user.

Individual accounts help you identify who accessed a system and revoke that person's access when they leave. Shared accounts make both tasks harder.

Step 2: test access permissions

Users should only be able to access information they are authorised to see. Test this before launch instead of assuming the application handles permissions correctly.

Create two test users belonging to separate organisations. Try using one user's login session to access information belonging to the other. If the application reveals data the user should not see, fix the problem before launch.

Add these checks to your automated testing process so future code changes do not reintroduce the same vulnerability.

Step 3: scan for exposed credentials

Passwords, API keys and other credentials can remain in a code repository's history after the relevant file has been deleted. Scanning only the current files may miss them.

Use tools such as Gitleaks or TruffleHog to scan the entire repository history. If a credential is still active, revoke or replace it before cleaning up the history. Rewriting the repository does not remove copies already held in other developers' clones or forks.

Add checks that scan for secrets before code is committed or uploaded. Enable built-in secret protection where available. GitHub, for example, enables push protection by default for public repositories.

Newer tools are also targeting this stage of development. openqodex is an open-source tool that reviews code before it is uploaded and includes secret scanning. It was created on 2 October 2026 and had 573 stars nine days later. That early interest suggests demand for this type of protection, but it does not establish the tool's maturity or effectiveness.

Step 4: review third-party access

Create a single inventory of every external party and connected system that can access your environment. Include vendors, contractors, integrations, third-party applications and automated processes used to build or deploy your software.

For each entry, record what it can access, which account or credential it uses, and who is responsible for removing its access. Remove permissions that exceed what the person or service needs to do its job.

Review the inventory whenever someone leaves, a supplier relationship ends or an integration is no longer needed. This prevents forgotten accounts and credentials from becoming overlooked entry points.

Step 5: apply security updates and configure alerts

Enable automatic updates for software dependencies and decide who is responsible for applying security fixes. Set a clear timeframe for addressing vulnerabilities, prioritising serious issues and services exposed to the internet.

Identify the services that can be reached from the public internet so the team knows what needs particular attention. Then configure at least one alert for unusual traffic, spending or data exports. Send it to a named person or a channel someone actively monitors.

An alert is useful only if someone receives it and knows what to do next. The aim is to detect suspicious activity early enough to investigate and respond.

Step 6: test backup recovery

Do not assume a backup will save your business simply because the backup process reports success. Restore a copy of the production database into a clean environment, check that the restored data is usable and measure how long recovery takes.

The US Cybersecurity and Infrastructure Security Agency's ransomware guide recommends encrypted, offline backups and regular testing to confirm that they are available and intact. It also recommends auditing user and administrator accounts for inactive or unauthorised access, including third-party access.

A backup that has never been restored is an untested assumption, not a proven recovery plan.

The checklist is broadly the same whether a startup has two engineers or ten. What changes as the business grows is how often these controls need to be reviewed and how consistently they must be applied.

Our MVP development guide explains where security fits into the launch plan. For a practical example of why software dependency updates matter, see what the package registry attack teaches.

When are a pentest and SOC 2 worth paying for?

Pay for a penetration test or SOC 2 when a specific customer or investor asks for independent security evidence, and your product is stable enough for the results to remain relevant. Until then, focus on fixing vulnerabilities and maintaining the security controls you already have.

The UK's National Cyber Security Centre (NCSC) explains in its penetration testing guidance that a test can only assess whether systems are vulnerable to known issues at the time of testing. It should support your vulnerability management process, not replace it.

For founders, the distinction is important: a penetration test checks your security work; it does not do that work for you. If your product's access permissions change every week, a report may describe a system that no longer exists by the time a customer reads it.

The OWASP Web Security Testing Guide makes a related point: no single testing method is sufficient, and leaving all security testing until development is complete is inefficient and ineffective. The pre-launch checklist addresses vulnerabilities as part of development. A penetration test provides an independent assessment once the product is sufficiently stable.

SOC 2 serves a different purpose. The American Institute of Certified Public Accountants (AICPA) describes SOC 2 as a report on controls relevant to security, availability, processing integrity, confidentiality or privacy. It helps customers assess the risks of outsourcing services to your business.

In practice, SOC 2 is evidence for your customers. If no prospective customer requires it and it will not help you win business, the expense may be premature. If enterprise procurement requires a report before signing a contract, it can become a commercial necessity.

What do a penetration test and SOC 2 cost?

Pricing varies by provider, scope and the complexity of your systems. Auditors do not publish a universal price list, and independent data on what startups actually pay is limited. The figures below are estimates published by compliance vendors, so treat them as starting points for requesting quotes rather than guaranteed prices.

Sources: Drata's SOC 2 cost guide and SecureLeap's SOC 2 cost guide.

These estimates may not cover the same scope or include the same services, so they are not directly comparable. Request at least three quotes based on a written scope. Ask what is included, what costs extra and what work your team must complete before the assessment.

The practical rule is to build and maintain security before paying someone to verify it. A penetration test helps identify weaknesses in a defined scope at a particular point in time. SOC 2 helps customers assess your controls through a formal report. Neither replaces the ongoing work of keeping your product secure.

Where RocketDevs fits

The cheapest time to address a security vulnerability is while the software is being built. If developers enforce access permissions on the server and prevent passwords or API keys from entering the code repository, they avoid problems that can be expensive to fix after launch. Three of the five security gaps discussed above, access control, exposed secrets and software vulnerabilities, can be reduced through everyday development practices and careful code review, long before a formal security test takes place.

This is where the quality of your engineering team matters. RocketDevs assesses each developer over 6-8 hours before placement and accepts only the top 2% of candidates. What you need from those developers is a contribution to the product's security as well as its functionality. That means checking who can access what, handling credentials properly, addressing vulnerable software dependencies and making security part of the development process rather than leaving it until launch.

How developers access your systems matters, too. RocketDevs developers work in your accounts under your identity provider, using individual logins. Your startup therefore retains control over permissions: you decide which systems each developer can access, limit those permissions to what the work requires, and revoke access when the engagement ends. This helps you manage the risks associated with third-party access without relying on shared credentials.

RocketDevs also offers a 14-day money-back trial, giving you an opportunity to assess whether a developer is the right fit before committing further. We have honoured the refund arrangement every time.

If your startup is two to eight weeks from launch and you need additional engineering capacity, RocketDevs can help you build a vetted development team. Put the five-door security review into the team's first week so that account permissions, credential handling, software updates, monitoring and backup recovery are addressed alongside product development.

For a broader view of how engineering capacity and operational processes change as a business grows, see our guide to scaling a startup.

Conclusion: close the five security gaps before you scale

Startup security is like securing a house before moving in. You do not wait for a break-in to install locks or test the alarm. Yet startups often launch with weak access controls, exposed credentials and untested backups, then spend more fixing these problems when customers and investors start asking questions.

Before launch, take five practical steps:

• Secure accounts: give every employee and contractor an individual login, enable multi-factor authentication (MFA), and remove access as soon as someone leaves.
• Test access permissions: check that users cannot view or change another user's data by manipulating requests. Fix any failures and add automated tests to catch regressions.
• Find and remove exposed secrets: scan the full code history for passwords and API keys, revoke or replace any active credentials you find, and enable checks to prevent new secrets from being committed.
• Control third-party access: list every vendor, contractor and connected application with access to your systems. Limit permissions to what each needs and assign someone to review and revoke access.
• Patch, monitor and recover: enable security updates, assign responsibility for fixing vulnerabilities, send alerts for suspicious activity to someone who can respond, and test that your backups can be restored.

Once these controls are in place and your product is stable, consider an independent penetration test. Invest in SOC 2 when a customer or investor requires the report or it will help you win business.

Do not wait for a security incident to discover what your startup left exposed. Assign an owner to each of the five gaps, work through the checklist before launch, and verify that every fix works. If your team needs development support, RocketDevs can connect you with vetted developers, with assessments lasting 6-8 hours and only the top 2% accepted. Your security still depends on the controls you put in place, so build those into the work from day one. The goal is not simply to launch faster. It is to launch with a product your customers can trust and a foundation you can scale with confidence.

Frequently asked questions

Does a startup need a penetration test before launch?

Usually, not as the first step. The UK NCSC describes penetration testing as a way to check how well your vulnerability management works against known issues at the time of the test, not as a substitute for fixing basic security gaps. Review the five doors first, then consider a test once the product is stable and a customer or investor needs independent assurance. If you have no in-house technical expertise to review security, an external test may be your best independent check.

When does a startup need SOC 2?

When a customer requires the report as part of its procurement process or it will help you win business. SOC 2 is an independent report prepared by a CPA that assesses controls against criteria such as security, availability and confidentiality. You should establish the controls early, but you do not necessarily need to pay for an audit before a deal depends on it.

What is the most common way startups get hacked?

There is no single answer for every startup. Verizon's 2026 Data Breach Investigations Report attributes the initial access in 31% of breaches to exploitation of vulnerabilities, while Mandiant's 2026 M-Trends report puts exploitation at 32% of intrusions. Stolen or reused credentials and third-party access are also major risks. These figures cover broader groups of organisations, not seed-stage startups specifically, but they show why patching, individual accounts and controlled vendor access matter.

How much should a seed-stage startup spend on security?

Start with engineering time rather than expensive audits. You can strengthen the five security areas using tools you may already have, such as multi-factor authentication, automated dependency updates, cloud billing alerts and open-source secret scanners such as Gitleaks. Budget for a penetration test or SOC 2 audit when your product, risk level or a customer requirement justifies the expense. Get quotes against a clearly defined scope rather than relying on generic estimates.

Do contractors need their own accounts?

Yes. Give every contractor an individual account with multi-factor authentication and only the permissions needed for their work. Shared logins make it difficult to track who did what and remove one person's access without disrupting everyone else. Revoke each contractor's access when their engagement ends, and check that any accounts or credentials they used are no longer active.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• Verizon, 2026 Data Breach Investigations Report, incidents from 1 November 2024 to 31 October 2025, and the news release, 19 May 2026
• Mandiant, M-Trends 2026: Data, Insights, and Strategies From the Frontlines, Google Cloud, 23 March 2026
• SecurityScorecard, 2025 Global Third-Party Breach Report press release, 26 March 2025
• OWASP Foundation, Top 10 2025, A01 Broken Access Control
• MITRE, 2025 CWE Top 25 Most Dangerous Software Weaknesses
• GitGuardian, The State of Secrets Sprawl 2026, 17 March 2026
• Truffle Security, GitHub Repos Exposed 543,699 Credentials. Nobody Revoked Them., 29 September 2026
• Meli, McNiece and Reaves, How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories, NDSS 2019
• GitHub, GitHub found 39M secret leaks in 2024, The GitHub Blog, 1 April 2025
• GitHub Docs, Removing sensitive data from a repository
• GitHub REST API, gitleaks and openqodex repository data, read 11 October 2026
• Meyer, Romero, Bertoli, Burt, Weinert and Lavista Ferres, How effective is multifactor authentication at deterring cyberattacks?, arXiv:2305.00945
• CISA, More than a password
• CISA, Product Security Bad Practices, version 2.0, January 2025
• CISA, Known Exploited Vulnerabilities catalog, release of 8 October 2026
• CISA, #StopRansomware Guide
• NIST, SP 800-63B, Authentication and Authenticator Management
• UK National Cyber Security Centre, Most hacked passwords revealed, 21 April 2019
• UK National Cyber Security Centre, Cyber Essentials overview
• UK National Cyber Security Centre, Penetration testing guidance
• UK Department for Science, Innovation and Technology and Home Office, Cyber Security Breaches Survey 2025/2026, 30 April 2026
• OWASP Foundation, Web Security Testing Guide, Introduction
• AICPA and CIMA, SOC 2
• Amazon Web Services, MFA for the AWS account root user and AWS Cost Anomaly Detection
• Drata, How Much Does a SOC 2 Audit Cost?, 25 March 2026
• SecureLeap, SOC 2 Certification Cost in 2026, 12 September 2026
• CPR-kontoret, Omfattende uautoriseret adgang til borgeres CPR-oplysninger, 5 October 2026
• Danish Ministry of Higher Education and Science, press release, 5 October 2026
• TV 2, live coverage, 5 October 2026, and Nye detaljer om cpr-skandale, 9 October 2026
• The Copenhagen Post (Ritzau), CPR data breach exposes personal details of 8.8 million people, 5 October 2026, and '123456' password used in massive Danish CPR data breach, 10 October 2026, reporting Politiken
• DR, 1039 virksomheder har fået indskærpet sikkerhed efter CPR-læk, October 2026
• Hacker News discussion of the CPR announcement, via the Algolia API
• Wikimedia pageviews API, Danish Wikipedia, CPR-nummer, 20 September to 10 October 2026