# The future of cybersecurity: the defence trends shaping 2030

> Where cyber defence is heading to 2030: zero trust, passkeys, post-quantum crypto, secure by design, SBOMs, AI, and the NIS2, CRA, SEC and UK rules.

- URL: https://computese.com/the-future-of-cybersecurity-2/
- Author: Duong Quan Nguyen, CEO, Computese
- Published: 2024-10-09
- Updated: 2026-09-25
- Topics: Security

## In short
- Cyber defence is moving from perimeters and passwords to checked requests and phishing-resistant sign-in: zero trust (NIST SP 800-207) and passkeys, which the UK NCSC has recommended over passwords since April 2026.
- Responsibility is shifting to software makers: CISA's Secure by Design pledge, memory-safe languages, SBOMs and SLSA build provenance, and the EU Cyber Resilience Act's product rules from December 11, 2027.
- Incident reporting now runs on a clock: 24-hour early warnings under NIS2 and the CRA (reporting since September 11, 2026), four business days after materiality for SEC filers, and 24 hours in the UK bill still before Parliament.
- Post-quantum migration has dates: NIST's draft plan deprecates 112-bit RSA and elliptic-curve algorithms after 2030 and disallows them after 2035; the UK NCSC wants discovery done by 2028.
- For a small or mid-sized organization, the next 12 months mean passkeys for key accounts, an inventory of what you expose and what cryptography you run, supplier questions, and an incident reporting runbook.

The future of cybersecurity is less about new tools than new defaults. Between now and 2030, defence is moving from perimeters to zero trust, from passwords to passkeys, from RSA and elliptic curves to post-quantum cryptography, and from buyer beware to secure by design, while laws in the EU, US and UK put incident reporting on a clock.

This guide takes each defensive shift with its primary source and date, then the regulations that change what organizations must do, and a 12-month plan for a small or mid-sized organization. Forecasts are labelled as forecasts and attributed. Two related subjects have their own posts: how attackers and defenders both use AI is in [the dual role of AI in cybersecurity](https://computese.com/the-dual-role-of-ai/), and quantum computing's wider effect on IT is in [how quantum computing could transform IT](https://computese.com/how-quantum-computing-could-transform-it/). Predicting which threats to patch first, with threat intelligence and exploit scoring, is covered in [which vulnerabilities to patch first](https://computese.com/the-future-of-cybersecurity/); this post is about the defensive changes.

## Zero trust: stop trusting the network

Zero trust means no user or device is trusted because of where it sits. [NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final), published in August 2020, defines it as moving defences from static, network-based perimeters to users, assets and resources. A laptop on the office LAN gets no more implicit trust than one on hotel Wi-Fi, and a company-owned device gets none simply for being company-owned. Authentication and authorization, of both the user and the device, happen before each session with a resource is set up.

The reason is practical. Staff work remotely, data lives in SaaS and cloud platforms, and an attacker who phishes one account or compromises one VPN appliance lands inside the old perimeter. On a flat network that foothold reaches everything. Under zero trust it reaches only what that identity and device are allowed to use, and only after a fresh check.

![Two laptops, one inside a dashed office network and one outside it, both pass through the same orange checkpoint that checks identity and device before a line reaches the application server.](https://computese.com/images/blog/the-future-of-cybersecurity-2/zero-trust.56b7977095-1536.webp)

*Inside the office or at home, every request meets the same check, so a foothold on the network opens nothing by itself.*

Progress can be measured. CISA's [Zero Trust Maturity Model 2.0](https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf), published in April 2023 for US federal agencies and aligned with the US federal zero trust strategy in OMB memorandum M-22-09, splits the work into five pillars: identity, devices, networks, applications and workloads, and data. Three cross-cutting capabilities run through them (visibility and analytics, automation and orchestration, and governance), and each pillar moves through four stages: traditional, initial, advanced and optimal. For the people building it, NIST's practice guide [SP 1800-35](https://csrc.nist.gov/pubs/sp/1800/35/final), finalized in June 2025, documents 19 example zero trust implementations assembled from commercial products with 24 collaborators.

Zero trust is an architecture, not a product. Identity providers, device management, zero trust network access (ZTNA) and microsegmentation tools each supply a part. For most small organizations the first real step is the identity pillar: one identity provider in front of every application, strong sign-in, and access rules that check the device as well as the user. Retiring network-wide VPN access in favour of per-application access comes after that.

## Passkeys: the password is on its way out

A [passkey](https://fidoalliance.org/passkeys/) is a FIDO sign-in credential: a cryptographic key pair created for one website or app, with the private key kept on a phone, a computer or a hardware security key and unlocked with the same fingerprint, face or PIN that unlocks the device. There is no shared secret for the site to leak and nothing a user can type into a fake page. Passkeys come in two forms. Synced passkeys are copied between a user's devices by a passkey provider, such as the platform's password manager or a third-party one; device-bound passkeys never leave one device, such as a FIDO security key.

The turning point came in April 2026. At its CYBERUK conference on April 23, the UK's National Cyber Security Centre announced it would [no longer recommend passwords where passkeys are available](https://www.ncsc.gov.uk/news/ncsc-leave-passwords-in-the-past-passkeys-are-the-future): passkeys should be consumers' first choice, and businesses should offer them to consumers as the default. The NCSC cited Google data showing that just over half of active Google users in the UK already had a passkey registered. The [technical assessment behind the decision](https://www.ncsc.gov.uk/blogs/passkeys-are-more-secure-than-traditional-ways-to-log-in) is blunt. Every traditional form of multi-factor authentication (MFA), including SMS codes, email codes, authenticator-app codes and push approvals, is inherently phishable, because the code or approval can be relayed during a live session. FIDO2 credentials, passkeys included, are as secure as or more secure than traditional MFA against every common credential attack seen in the wild, and they count as multi-factor when the device verifies the user.

Adoption is past the early-adopter stage too: in a 2024 survey commissioned by the FIDO Alliance, 53% of people said they had enabled passkeys on at least one account.

For an organization, this is two decisions:

- **Staff sign-in.** Turn on passkeys in your identity provider, starting with administrators. [Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkeys-fido2), for example, supports both synced and device-bound passkeys and lets administrators set, group by group through passkey profiles, which types are allowed.
- **Customer sign-in.** If you run a login for customers, offer passkeys as the default, as the NCSC now recommends. Where a service cannot support them yet, the NCSC's fallback advice is a password manager plus two-step verification.

> [!TIP]
> Design account recovery with the same care as sign-in. A phishing-resistant passkey behind an email-reset link that anyone can trigger just moves the attack to the reset flow.

## Post-quantum cryptography: a migration with deadlines

A large enough quantum computer could break the encryption that protects almost everything done online, and NIST reported in 2024 that some experts predict such a machine could appear within a decade. The replacements are ready: in August 2024 NIST published [FIPS 203, 204 and 205](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards), standardizing ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures, and urged administrators to start integrating them immediately. The deadlines are set too. NIST's [draft transition plan, IR 8547](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf), names the protocols at risk (TLS, SSH, IPsec VPNs and code signing among them), warns that data recorded today can be decrypted later ("harvest now, decrypt later"), and proposes deprecating RSA and elliptic-curve algorithms at 112-bit security strength after 2030 and disallowing them after 2035. The UK NCSC's [migration timelines](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines) ask organizations to finish discovery and an initial plan by 2028, their highest-priority migrations by 2031 and everything by 2035. Our guide to [quantum computing in cybersecurity](https://computese.com/quantum-computing-in-cybersecurity-breakthrough/) covers the evidence, every deadline and a step-by-step migration plan; the short version is to inventory where you use public-key cryptography now, because every later step depends on that list.

## Secure by design: the burden moves to software makers

The most consequential shift may be about who does the work. CISA's [Secure by Design](https://www.cisa.gov/securebydesign) initiative argues that the burden of cybersecurity has fallen disproportionately on consumers and small organizations instead of on the companies that make the technology, and that products should be secure out of the box, with MFA, logging and single sign-on (SSO) included at no extra cost.

On May 8, 2024, [68 software manufacturers signed CISA's Secure by Design pledge](https://www.cisa.gov/news-events/news/cisa-announces-secure-design-commitments-leading-technology-providers), a voluntary commitment to show measurable progress within a year on seven goals:

1. More use of multi-factor authentication across their products.
2. Fewer default passwords.
3. A measurable reduction in one or more entire classes of vulnerability.
4. More customers installing security patches.
5. A published vulnerability disclosure policy.
6. Accurate CWE and CPE fields in CVE records, and timely CVEs for critical or high-impact flaws.
7. Better evidence of intrusions for customers, such as audit logs.

As of September 2026, CISA's Secure by Design page counts more than 200 manufacturers that have taken the pledge.

Eliminating a class of vulnerability is where memory-safe languages come in. Buffer overflows and use-after-free bugs come from languages such as C and C++ that leave memory management to the programmer; a memory-safe language such as Rust prevents them by design. In June 2025 CISA and the NSA published [joint guidance on adopting memory-safe languages](https://www.cisa.gov/resources-tools/resources/memory-safe-languages-reducing-vulnerabilities-modern-software-development), covering the obstacles and how organizations can get past them.

Some of the clearest public evidence comes from Android. Google began moving new Android development to memory-safe languages around 2019, and [memory-safety issues fell from 76% of Android vulnerabilities in 2019 to 24% in 2024](https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html), against an industry norm of about 70%, even though most of the code base was still memory-unsafe. In [2025 they fell below 20% for the first time](https://blog.google/security/rust-in-android-move-fast-fix-things/), and Google estimated the memory-safety vulnerability density of its Rust code at more than 1,000 times lower than its C and C++. The lesson for any team that builds software is that you do not have to rewrite old code to benefit: citing a 2022 USENIX Security study, Google notes that most vulnerabilities sit in new or recently modified code, so writing new code in a memory-safe language does most of the work. For the habits that prevent the other common flaw classes, see our [secure coding checklist](https://computese.com/best-practices-for-secure-coding/).

## Software supply chain security: SBOMs and build provenance

Applications are assembled from other people's code and built on other people's platforms, which makes suppliers a way in. In its [foresight study of threats for 2030](https://www.enisa.europa.eu/sites/default/files/publications/ENISA%20Foresight%20Cybersecurity%20Threats%20for%202030.pdf), published in March 2023, ENISA, the EU's cybersecurity agency, ranked supply chain compromise of software dependencies first among 21 threats it expects to grow by 2030. That is a forecast, but the defences are already standardizing around two artifacts.

A [software bill of materials (SBOM)](https://computese.com/sbom/) is the ingredients list: every component and version inside a piece of software, so that when a vulnerability is disclosed in a library you can tell which of your products contain it. On July 29, 2026, CISA, the NSA, the FBI and international partners published the [2026 Minimum Elements for an SBOM](https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom), which replaces the NTIA's 2021 minimum elements and reflects the tools now in use.

Build provenance answers a different question: was this package built from the source it claims, on the platform it claims, without tampering? [SLSA](https://slsa.dev/spec/v1.2/) (Supply-chain Levels for Software Artifacts) defines it in levels. Version 1.2 adds a Source track, covering the source code itself, alongside the [Build track](https://slsa.dev/spec/v1.2/build-track-basics):

| Build level | What it requires                                        | What it protects against      |
| ----------- | ------------------------------------------------------- | ----------------------------- |
| L0          | Nothing                                                 | Nothing                       |
| L1          | Provenance showing how the package was built            | Mistakes; documents the build |
| L2          | Signed provenance, generated by a hosted build platform | Tampering after the build     |
| L3          | A hardened build platform                               | Tampering during the build    |

![Code moves from a repository to a hosted build server, which ships a package with an orange signed provenance card and a component list. A laptop checks the card with a magnifying glass before installing.](https://computese.com/images/blog/the-future-of-cybersecurity-2/provenance.ad8f41dc95-1536.webp)

*Provenance lets a customer check where a package was built before trusting it; the SBOM says what is inside.*

The EU is turning the SBOM into law. From December 11, 2027, the [Cyber Resilience Act's text](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng) requires manufacturers to draw up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies of their products.

Buyers can ask for all of this now. CISA's [Secure by Demand guide](https://www.cisa.gov/resources-tools/resources/secure-demand-guide) turns it into procurement questions: an SBOM in a standard machine-readable format, a roadmap for eliminating classes of vulnerability (a memory-safe roadmap, for example), SSO at no additional cost, MFA or passkeys by default, and, from SaaS providers, security logs kept for at least six months at no additional charge.

## AI on both sides of the fight

AI speeds up attackers and defenders alike, and the most useful forecasts say so plainly. The UK NCSC's [assessment of AI's impact on the cyber threat to 2027](https://www.ncsc.gov.uk/report/impact-ai-cyber-threat-now-2027), published in May 2025, judges that AI will almost certainly make parts of intrusion operations more effective and efficient, increasing the frequency and intensity of threats, and that the time between a vulnerability's disclosure and its exploitation, already down to days, will shrink further. It also predicts a digital divide between systems that keep pace with AI-enabled threats and a large proportion that stay more vulnerable. The defensive consequence matches the rest of this guide: know what you expose, patch it faster, and automate what you can. How attackers use AI for phishing, deepfakes and malware, and the control that answers each, is in [the dual role of AI in cybersecurity](https://computese.com/the-dual-role-of-ai/); how security teams use AI for detection and triage is in [AI in cybersecurity](https://computese.com/teh-crucial-role-in-ai-in-cybersecurity/).

## The regulations that change what organizations must do

Regulation is the trend with the firmest dates. Four regimes matter most for organizations that operate in or sell into the EU, the US and the UK.

### EU NIS2 directive

[NIS2](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive), Directive (EU) 2022/2555, replaced the EU's first NIS directive and sets cybersecurity duties for medium-sized and large entities in 18 critical sectors, from energy, health and digital infrastructure to postal services, waste management, critical product manufacturing and public administration. Member states had until October 17, 2024 to transpose it into national law.

Under [the directive's text](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng), covered entities must take risk-management measures that explicitly include supply chain security, policies on the use of cryptography, and multi-factor authentication; their management bodies must approve those measures. A significant incident triggers an early warning within 24 hours, an incident notification within 72 hours and a final report within a month. Maximum fines must reach at least €10 million or 2% of worldwide annual turnover for essential entities, and €7 million or 1.4% for important ones.

Transposition ran late. After letters of formal notice in November 2024 and reasoned opinions in May 2025, the Commission on July 8, 2026 [referred Ireland, Spain, France and the Netherlands to the Court of Justice](https://digital-strategy.ec.europa.eu/en/news/commission-refers-ireland-spain-france-and-netherlands-court-justice-failing-transpose-rules) for still not notifying full transposition, and asked for financial penalties; it says most member states have complied. The rules may change at the edges: on January 20, 2026 the Commission proposed targeted amendments to simplify compliance, which it says would ease the burden on 28,700 companies, including 6,200 micro and small enterprises. A proposal still has to pass the European Parliament and the Council before it changes anything.

### EU Cyber Resilience Act

The [Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) (CRA), Regulation (EU) 2024/2847, covers hardware and software products with digital elements sold in the EU and puts the security obligations on their manufacturers. It entered into force on December 10, 2024.

Its [reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) have applied since September 11, 2026. Manufacturers must report actively exploited vulnerabilities and severe incidents affecting their products with an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days of a fix being available (for vulnerabilities) or within a month of the notification (for incidents). Each report is filed once, through ENISA's Single Reporting Platform, and goes to the national CSIRT where the manufacturer is established, with ENISA informed at the same time; that CSIRT shares it with the CSIRTs of the other countries where the product is sold.

![A manufacturer's server beside a boxed product sends one orange report to a central platform, which passes it to several national response teams and an EU agency. A clock sits above the first arrow.](https://computese.com/images/blog/the-future-of-cybersecurity-2/reporting.0aaace14f7-1536.webp)

*Under the CRA a manufacturer files once; the platform, not the manufacturer, gets the report to every national team concerned.*

The main obligations apply from December 11, 2027: cybersecurity requirements for design, development and maintenance, vulnerability handling for a support period of at least five years unless the product is expected to be in use for less, the SBOM described above, and CE marking to show conformity. The Commission published practical guidance for manufacturers on July 27, 2026.

> [!IMPORTANT]
> If you make software or connected devices sold in the EU, the CRA's 24-hour reporting duty for actively exploited vulnerabilities already applies, even though its product requirements wait until December 2027.

### US SEC cyber incident disclosure rule

In the US, the [SEC rule adopted on July 26, 2023](https://www.sec.gov/newsroom/press-releases/2023-139) requires public companies to disclose a material cybersecurity incident on Form 8-K under Item 1.05, describing its nature, scope and timing and its material impact, generally within four business days of determining that the incident is material. The clock starts at that determination, not at discovery. Disclosure can be delayed only if the US Attorney General finds that it would pose a substantial risk to national security or public safety. Annual reports must also describe, under Regulation S-K Item 106, how the company assesses and manages cybersecurity risk and how its board oversees it. The 8-K requirement has applied since December 18, 2023, with smaller reporting companies given 180 more days.

### UK Cyber Security and Resilience Bill

The UK is updating its NIS Regulations 2018 with the [Cyber Security and Resilience (Network and Information Systems) Bill](https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/summary-of-the-bill). It brings medium and large managed service providers, data centres and large load controllers into scope, and lets regulators designate critical suppliers. More kinds of harmful incidents would have to be reported, with an initial notification within 24 hours and a fuller report within 72 hours, and the NCSC informed at the same time. Data centres and digital and managed service providers would also have to tell customers likely to be affected.

As of September 2026 it is not yet law. The bill was introduced in the Commons on November 12, 2025, carried over into the new session, passed its Commons third reading on June 16, 2026 and went through Lords committee stage in September. [Lords report stage](https://bills.parliament.uk/bills/4035/stages) is provisionally set for October 26, 2026. After Royal Assent, the government says, it will come into force in phases, some measures only through later secondary legislation. If you are a managed service provider with UK clients, or rely on one, this is the bill to watch.

### The reporting clocks side by side

| Regime      | Who reports                                                      | Deadlines                                                     | Status, September 2026                     |
| ----------- | ---------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------ |
| EU NIS2     | Medium and large entities in 18 critical sectors                 | 24 hours, 72 hours, one month                                 | In force; four states referred to court    |
| EU CRA      | Manufacturers of products with digital elements                  | 24 hours, 72 hours, 14 days after a fix or one month          | Reporting applies since September 11, 2026 |
| US SEC rule | Public companies (SEC registrants)                               | Form 8-K within four business days of deciding it is material | Applies since December 18, 2023            |
| UK bill     | Essential and digital services, MSPs, data centres (as proposed) | 24 hours, 72 hours                                            | Before the House of Lords                  |

## Cybersecurity trends to 2030: the dated milestones

Most trend lists for 2030 are forecasts. These dates are already set, and they give the next few years their shape:

| When                           | What happens                                                                                                  |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------- |
| September 11, 2026             | EU CRA reporting of exploited vulnerabilities and severe incidents begins                                     |
| October 26, 2026 (provisional) | UK Cyber Security and Resilience Bill reaches report stage in the House of Lords                              |
| December 11, 2027              | EU CRA main obligations apply, including SBOMs and support periods                                            |
| 2028                           | UK NCSC target: cryptography discovery and an initial PQC migration plan complete                             |
| After 2030                     | NIST draft plan: 112-bit RSA and elliptic-curve algorithms deprecated                                         |
| 2031                           | UK NCSC target: highest-priority PQC migrations complete                                                      |
| 2035                           | NCSC target for full PQC migration; after 2035, NIST's draft plan disallows RSA and elliptic-curve algorithms |

Everything else about 2030 is prediction, and worth reading as such. ENISA expects supply chain compromise to be the leading emerging threat. The NCSC expects AI to widen the gap between well-defended and poorly defended systems. NIST notes that some experts expect a quantum computer able to break current encryption within a decade of 2024. None of these forecasts changes the order of work below.

## What a small or mid-sized organization should do in the next 12 months

You do not need to adopt every trend at once. In rough order of return on effort:

1. **Move key accounts to passkeys.** Start with administrators, finance staff and anyone who can reset accounts or approve payments, then email and remote access for everyone. Keep two-step verification on as the fallback where passkeys are not supported yet.
2. **Put every application behind one identity provider,** with access rules that check the device as well as the user. This is the identity pillar of zero trust, and the one that pays off first.
3. **Know what you expose, and patch it faster.** List your domains, subdomains, public IP addresses, certificates and cloud accounts, and scan them on a schedule. Our [security testing service](https://computese.com/services/security-testing/) discovers what you have online, scans your websites, servers and cloud accounts on a schedule, ranks findings by exploitability as well as severity, and re-tests each fix.
4. **Write the incident reporting runbook now.** Work out which regimes apply to you or your customers (NIS2 as an entity or a supplier, the CRA as a manufacturer, the SEC rule through listed customers, the UK bill as an MSP or data centre), who decides that an incident is reportable, and who files within 24 hours. The day of an incident is too late to find the form.
5. **Ask suppliers the Secure by Demand questions** at every renewal: an SBOM, MFA and SSO without extra cost, how patches reach you, and how long logs are kept.
6. **If you ship software, generate an SBOM on every build** and move builds to a hosted platform that signs provenance (SLSA Build L2). Write new code in a memory-safe language where you can. If you sell in the EU, map the CRA to your products and their support periods before December 2027.
7. **Start the cryptography inventory.** List where RSA and elliptic-curve keys protect TLS, VPNs, SSH, code signing and vendor products. It is the NCSC's first milestone, and it also shows where certificates are still renewed by hand, which our guide to [renewing an SSL certificate](https://computese.com/ssl-certificate/) helps automate.

None of this replaces the basics. Our [small business cybersecurity checklist](https://computese.com/cybersecurity-best-practices/) covers backups, patching, email authentication and the rest in priority order, and the trends above build on it rather than around it.

## Key terms
- **Zero trust architecture**: A security design in which no user or device is trusted because of its network location or ownership. Each request to a resource is authenticated and authorized first, as NIST SP 800-207 describes.
- **Passkey**: A FIDO sign-in credential: a key pair made for one site, with the private key kept on a phone, computer or security key and unlocked like the device. Synced passkeys move between a user's devices; device-bound ones never leave one.
- **Phishing-resistant authentication**: Sign-in that a fake website cannot capture and replay, because the credential is cryptographically bound to the real service. Passkeys and other FIDO2 credentials qualify; SMS, email and app codes and push approvals do not.
- **Post-quantum cryptography (PQC)**: Public-key algorithms designed to resist attack by a future quantum computer, such as ML-KEM, ML-DSA and SLH-DSA, standardized by NIST in FIPS 203, 204 and 205 in August 2024.
- **Secure by design**: The principle, promoted by CISA, that software makers build security into products from the start and ship them secure by default, instead of leaving customers to add it.
- **Memory-safe language**: A programming language, such as Rust, that prevents memory errors like buffer overflows by design, removing a class of vulnerability common in C and C++ code.
- **SBOM (software bill of materials)**: A machine-readable list of the components and versions inside a piece of software, used to find where a newly disclosed vulnerability applies.
- **SLSA build provenance**: A signed record, defined by the SLSA framework, of how, where and from what source a software package was built, so a consumer can check it was not tampered with.
- **NIS2**: EU Directive 2022/2555, which sets cybersecurity risk-management and incident reporting duties for medium-sized and large entities in 18 critical sectors, applied through national law.
- **Cyber Resilience Act (CRA)**: EU Regulation 2024/2847, which sets cybersecurity requirements for hardware and software products sold in the EU, with vulnerability reporting from September 11, 2026 and full application from December 11, 2027.

## Common questions

### What is the future of cybersecurity?

Over the next five years, defence is moving from network perimeters and passwords to zero trust and passkeys, from customers carrying security to secure-by-design products with SBOMs, and from RSA and elliptic curves to post-quantum cryptography. Regulation adds the deadlines: EU Cyber Resilience Act reporting since September 2026, its product rules from December 2027, and post-quantum migration milestones from 2028 to 2035.

### What are the main cybersecurity trends to 2030?

The dated ones are regulatory and cryptographic: the EU Cyber Resilience Act fully applies from December 11, 2027, and NIST's draft plan deprecates 112-bit RSA and elliptic-curve algorithms after 2030. The rest are forecasts: ENISA ranks software supply chain compromise as the top emerging threat for 2030, and the UK NCSC expects AI to make intrusions more frequent and exploitation faster.

### Will passkeys replace passwords?

For most sign-ins, that is the direction. Since April 2026 the UK NCSC recommends passkeys wherever a service supports them and tells businesses to offer them to consumers as the default, with a password manager and two-step verification as the fallback. Passwords will linger on services that have not added passkeys yet.

### Is NIS2 in force in every EU country?

The deadline for national laws was October 17, 2024, and the European Commission says most member states have complied. In July 2026 it referred Ireland, Spain, France and the Netherlands to the Court of Justice for not notifying full transposition. Whether NIS2 applies to your company depends on your sector and size under the national law where you operate.

### When does the EU Cyber Resilience Act apply?

It entered into force on December 10, 2024. Manufacturers have had to report actively exploited vulnerabilities and severe incidents since September 11, 2026, and the main requirements, including an SBOM, a support period of at least five years in most cases and CE marking, apply from December 11, 2027.

### Is zero trust a product you can buy?

No. NIST describes zero trust as a set of principles for designing access, where nothing is trusted because of its network location. Identity providers, device management and per-application access tools supply parts of it, and CISA's Zero Trust Maturity Model is a way to measure how far along you are.

## Sources
1. [SP 800-207: Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final), NIST
2. [Zero Trust Maturity Model, Version 2.0](https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf), CISA
3. [SP 1800-35: Implementing a Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/1800/35/final), NIST
4. [Passkeys](https://fidoalliance.org/passkeys/), FIDO Alliance
5. [NCSC: Leave passwords in the past, passkeys are the future](https://www.ncsc.gov.uk/news/ncsc-leave-passwords-in-the-past-passkeys-are-the-future), UK National Cyber Security Centre
6. [Passkeys are more secure than traditional ways to log in](https://www.ncsc.gov.uk/blogs/passkeys-are-more-secure-than-traditional-ways-to-log-in), UK National Cyber Security Centre
7. [How to enable passkeys (FIDO2) in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkeys-fido2), Microsoft Learn
8. [NIST Releases First 3 Finalized Post-Quantum Encryption Standards](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards), NIST
9. [NIST IR 8547 (initial public draft): Transition to Post-Quantum Cryptography Standards](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf), NIST
10. [Timelines for migration to post-quantum cryptography](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines), UK National Cyber Security Centre
11. [Secure by Design](https://www.cisa.gov/securebydesign), CISA
12. [CISA Announces Secure by Design Commitments from Leading Technology Providers](https://www.cisa.gov/news-events/news/cisa-announces-secure-design-commitments-leading-technology-providers), CISA
13. [Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development](https://www.cisa.gov/resources-tools/resources/memory-safe-languages-reducing-vulnerabilities-modern-software-development), CISA and NSA
14. [Eliminating Memory Safety Vulnerabilities at the Source](https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html), Google Security Blog
15. [Rust in Android: move fast and fix things](https://blog.google/security/rust-in-android-move-fast-fix-things/), Google
16. [ENISA Foresight Cybersecurity Threats for 2030](https://www.enisa.europa.eu/sites/default/files/publications/ENISA%20Foresight%20Cybersecurity%20Threats%20for%202030.pdf), ENISA
17. [2026 Minimum Elements for a Software Bill of Materials (SBOM)](https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom), CISA
18. [SLSA specification, version 1.2](https://slsa.dev/spec/v1.2/), SLSA
19. [SLSA 1.2: Build track basics](https://slsa.dev/spec/v1.2/build-track-basics), SLSA
20. [Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem](https://www.cisa.gov/resources-tools/resources/secure-demand-guide), CISA
21. [Impact of AI on cyber threat from now to 2027](https://www.ncsc.gov.uk/report/impact-ai-cyber-threat-now-2027), UK National Cyber Security Centre
22. [NIS2 Directive: securing network and information systems](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive), European Commission
23. [Directive (EU) 2022/2555 (NIS2 Directive)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng), EUR-Lex
24. [Commission refers Ireland, Spain, France and the Netherlands to the Court of Justice for failing to transpose the rules on cybersecurity](https://digital-strategy.ec.europa.eu/en/news/commission-refers-ireland-spain-france-and-netherlands-court-justice-failing-transpose-rules), European Commission
25. [Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), European Commission
26. [Cyber Resilience Act: Reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting), European Commission
27. [Regulation (EU) 2024/2847 (Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng), EUR-Lex
28. [SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure by Public Companies](https://www.sec.gov/newsroom/press-releases/2023-139), U.S. Securities and Exchange Commission
29. [Cyber Security and Resilience (Network and Information Systems) Bill: summary of the Bill](https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/summary-of-the-bill), UK Government (DSIT)
30. [Cyber Security and Resilience (Network and Information Systems) Bill: stages](https://bills.parliament.uk/bills/4035/stages), UK Parliament