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, and quantum computing's wider effect on IT is in 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; 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, 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.
Progress can be measured. CISA's Zero Trust Maturity Model 2.0, 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, 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 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: 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 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, 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, 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, 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 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 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 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, a voluntary commitment to show measurable progress within a year on seven goals:
- More use of multi-factor authentication across their products.
- Fewer default passwords.
- A measurable reduction in one or more entire classes of vulnerability.
- More customers installing security patches.
- A published vulnerability disclosure policy.
- Accurate CWE and CPE fields in CVE records, and timely CVEs for critical or high-impact flaws.
- 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, 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, 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, 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.
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, 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) 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, 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 (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:
| 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 |
The EU is turning the SBOM into law. From December 11, 2027, the Cyber Resilience Act's text 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 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, 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; how security teams use AI for detection and triage is 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, 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, 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 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 (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 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.
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 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. 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 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:
- 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.
- 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.
- 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 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.
- 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.
- 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.
- 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.
- 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 helps automate.
None of this replaces the basics. Our small business cybersecurity checklist covers backups, patching, email authentication and the rest in priority order, and the trends above build on it rather than around it.
