Web security and privacy in 2026: what changed and what to do now

Website security and privacy changed more between 2024 and 2026 than in the previous decade. Passwords began giving way to passkeys, privacy law arrived in force on both sides of the border, accessibility became a hard legal deadline for many organisations, and AI introduced a class of risks that did not exist three years ago. The work is real, but it is finite: a business owner who understands the handful of shifts below can get ahead of nearly all of it in a single quarter.

What actually changed between 2024 and 2026?

Three forces converged. First, regulators stopped waiting: privacy and accessibility rules that had been drafted or delayed for years came into force with dates attached. Second, the tooling matured: passkeys, managed hosting, and automated dependency scanning made good security cheaper than it used to be, which quietly raised the standard a business is judged against. Third, AI changed both sides of the fight, giving attackers better phishing and scraping tools while giving businesses new ways to leak data without anyone breaking in.

The result is that "we have an SSL certificate" is no longer a security posture. Here is the shift in plain terms, and where each area is heading next.

Why are passkeys replacing passwords?

Passkeys solve the problem that passwords never could: people. A passkey is a cryptographic credential stored on your device and unlocked with a fingerprint, a face, or a device PIN. There is nothing to reuse across sites, nothing to type into a fake login page, and nothing for an attacker to steal from a breached database. The major platforms, Apple, Google, and Microsoft, all support them, and by 2026 many major consumer services offer them alongside passwords.

For a business website, the practical guidance is layered. If your site has customer accounts, offer passkeys where your platform supports it and require multi-factor authentication as the floor. For your own administrative logins, the ones that can take the whole site down, MFA is not optional, and hardware-backed methods beat codes sent by text message, which can be intercepted. One of the most common ways small-business websites get taken over is still a reused admin password, and that is entirely preventable.

Which privacy laws apply to your website now?

If you serve customers in Quebec, Law 25 applies to you, and it is fully in force, including its final provisions on data portability that landed in 2024. It requires a named privacy officer, consent that is genuinely informed rather than buried, breach reporting, and privacy impact assessments for certain projects. Enforcement carries meaningful penalties, and being based outside Quebec does not exempt you if Quebecers are your customers.

South of the border, comprehensive state privacy laws have gone from a novelty to a category. Texas's TDPSA, alongside laws in California, Colorado, Virginia, Connecticut, and a lengthening list of other states, means a Canadian business selling to Americans can face a dozen overlapping regimes. The good news is that they rhyme: collect less, explain clearly, honour deletion and opt-out requests, and secure what you keep. Build for the strictest law that applies to you and the rest largely follows. To be clear, this article is general guidance, not legal advice; for your specific obligations, talk to a lawyer who works in privacy.

Practically, that means your cookie banner should reflect what your site actually does, your privacy policy should be written by someone who has seen your analytics configuration, and your forms should stop collecting fields you never use. Data you never collected is data you can never lose.

What is the ADA Title II web rule, and does it affect Canadians?

In 2024, the US Department of Justice finalised a rule under Title II of the Americans with Disabilities Act requiring state and local government websites and mobile apps to meet WCAG 2.1 Level AA. Larger public entities must comply by April 2026, smaller ones by April 2027. It is the first time the US has attached a specific technical standard and a hard date to web accessibility at this scale.

The rule directly binds US public entities, but its gravity is wider. Vendors who sell to those entities inherit the requirement through their contracts, private-sector accessibility litigation in the US continues to cite WCAG as the de facto measure, and Canadian regimes, from the Accessible Canada Act to provincial legislation in Ontario and elsewhere, point the same direction. Accessibility is also simply good engineering: semantic markup, keyboard navigation, and sensible contrast make sites faster, easier to maintain, and easier for search engines and AI assistants to read. We build to WCAG 2.2 AA on every project because retrofitting accessibility costs far more than building it in.

Why is your biggest risk probably a plugin?

Most compromised business websites are not attacked in any meaningful sense. They run a content management system with dozens of plugins and themes, one of those components ships a vulnerability, a patch is published, the site does not apply it, and automated scanners find it, often within days. The same pattern plays out in modern JavaScript projects, where a single application can pull in hundreds of open-source packages, any one of which can be abandoned, hijacked, or published with malicious code. Third-party scripts, for chat widgets, analytics, and ads, add another layer: code that runs on your pages but that you neither wrote nor review.

Your website is only as trustworthy as its least-maintained plugin.

The defences are unglamorous and effective: keep an inventory of what your site actually runs, remove what you do not use, apply updates on a schedule rather than when someone remembers, and prefer fewer, well-maintained components over many convenient ones. Those trade-offs shape how we choose a stack in our web development work.

What new risks did AI bring?

Three, mainly. The first is data leakage: staff pasting customer records, contracts, or credentials into public AI chatbots, where the business loses control of them. This is a policy and training problem more than a technical one, and the fix is to give people approved tools with clear rules rather than pretending they will abstain.

The second is prompt injection. If your site includes an AI feature, a support chatbot, a summariser, anything that feeds user input or web content into a language model, attackers can craft input that manipulates the model into ignoring its instructions, revealing data, or misusing whatever tools it is connected to. This class of attack has no complete fix at the time of writing, so AI features need to be designed defensively: least privilege, output checks, and no ability to take irreversible actions on their own. It is a core concern in our AI development work.

The third is scraping. AI crawlers now visit business websites in volumes that many site owners can see plainly in their logs, and content published openly may be collected for training or answered directly by AI assistants. Whether you welcome that or resist it is a business decision, but it should be a decision: robots directives, rate limiting, and licensing terms are the levers available today.

What should you do this quarter?

Here is the checklist we would hand any business owner in September 2026. None of it requires a big budget; all of it requires a decision.

1. Turn on multi-factor authentication for every administrative account: website, hosting, domain registrar, and email. Offer passkeys to customers where your platform supports them.
2. List every plugin, theme, and third-party script your site runs. Remove what you do not use. Put updates on a monthly schedule with someone's name attached.
3. Read your own privacy policy against what your site actually collects. Fix the gaps, trim the forms, and confirm you can honour a deletion request end to end.
4. Run an accessibility check against WCAG 2.2 AA and fix the failures that block real use: keyboard traps, missing labels, poor contrast.
5. Write a one-page AI policy for staff: which tools are approved, what data may never be pasted into them, and who to ask.
6. Confirm your backups exist, live somewhere separate from the site, and have actually been restored at least once.

How OlDevs approaches security and privacy

Security is not a service we sell separately; it is how we build. Every OlDevs project ships with MFA on administrative access, a maintained dependency inventory, WCAG 2.2 AA accessibility, and privacy-conscious defaults in analytics and forms, and clients own all code, accounts, and IP, so nothing about your security posture is held hostage to your vendor. We work as one accountable team from Vancouver, show a working demo every week, and document what we build so the next person can maintain it. If you want a plain-language read on where your website stands, or a partner to fix what this article surfaced, request a quote. We reply to every enquiry within one business day.