However, since then, things have changed. Let’s revisit those predictions and make some new ones.

1. The Threat Landscape is Changing

2023: Not really.
2026: AI has entered the chat. 

For 2023 I wrote, “everybody will experience the same quality and quantity of attacks that we did in 2022. The technologies, personnel, and practices may change causing us to perceive security differently. However, the actual threats we face will remain mostly the same.”

For the most part, this prediction remains the same. The threat landscape in 2026 will be about the same as 2025, 2024, 2023, and so on. Malware is still a threat. Credential theft remains the primary focus of attackers. And hackers still have the upper hand in every way.

However, when we look at AI systems, there are tremendous changes in the threat landscape. Perhaps the most interesting of these threats are data poisoning attacks. These specifically target AI systems and large language models (LLMs) to produce flawed or misleading output. In 2024, NIST released an advisory about this kind of attack based on a study they conducted titled Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. This study is an interesting read. It is extremely thorough and even identifies some lingering cybersecurity challenges such as the dilemma of open versus closed systems.

The mitigating factor with this kind of treat is that it targets the AI platforms, and not the end users of those platforms. This limits the scope of this threat to a handful of AI platform providers, such as OpenAI, Google, Microsoft, etc. Furthermore, I could not to locate any confirmed instance of a data poisoning attack, however that does not mean it has not happened.

What is a larger issue are employees sending company data into AI platforms with no regard to the sensitivity of that data. This poses a complex challenge for organizations who want to enjoy the benefits of AI but need to protect sensitive data. It also poses a massive challenge for regulated systems under standards such as FedRAMP, CMMC, etc.

Fortunately, the industry is responding to this with ample technologies to manage, monitor, and control AI access as well as model context protocol (MCP) servers. Some examples of AI security providers in this space include Obsidian, Zenity, and Cyberhaven.

2. Executives Will Start Taking Security Seriously

2023: Probably not.
2026: No, and you can turn in your badge with security. 

For 2023, I wrote, “Information security is an esoteric threat to executives. They know it exists, but they cannot quantify it with clear consequences. They know it is serious, but they do not know how to dimmish the threat. They know harm is possible, but it is easy to dismiss it as somebody else’s problem.”

Around 2016 or so, I noticed that many executives would tune out the moment cybersecurity was mentioned. I had CEOs once tell me he was sick of security slowing down his company. Here we are a decade later and this attitude has only become more prevalent. A recent example of this attitude happened in early 2025 when the Trump administration wiped out the entire Department of Homeland Security’s Cyber Safety Review board. The message was unambiguous: security is unimportant. 

Executive indifference to security is a massive barrier for security startups. Leaders only care about security when it becomes a catastrophe. And all they really want is to find somebody to blame.

3. Companies will Commit to Stronger Security Defenses

2023: No, they will stick with “good enough” security
2026: Good enough is pretty good.

What I wrote for 2023 remains relevant. “It is not that executives do not care at all about security. They care up until the exact point they are on par with everybody else. This is the “good enough” approach to cybersecurity. Companies focus on doing what is an “industry standard” rather than doing what is necessary.”

Fortunately, “good enough” security is getting pretty good. One example of this was AWS’s recent announcement of their security agent product. This is a cool new AI technology that can scan an environment, locate vulnerabilities, and suggest improvements. While no AI agent will ever be as good as a skilled human penetration tester, for most organization, this agent is all they really need.

Another good example of how “good enough” has improved is Azure Sentinel. What used to be a mediocre SIEM and endpoint product, has evolved into a respectable security platform. Azure environments have Sentinel built-in, so Azure customers can access and use it easily.

4. We Will See a Megabreach that Cannot be Ignored

2023: We are already ignoring them.
2026: Megabreaches, what’s that?

I cannot even think of a megabreach from 2025 that had any significant impact. Apparently, Verizon had a massive leak in August, which they denied. Whatever. This is a classic “boy cried wolf” problem.

5. Security Staffing will See Improvements

2023: Not likely.
2026: Define “improvements.”  

For 2023 I said, “Cybersecurity does not have a staffing problem; it has a staffing crappy jobs problem. There are ample people out there who want to pontificate about all their grand theories of security. What nobody wants to do is actually run anything.”

The most significant change for 2026 is that AI is changing who companies are hiring. AI can do what a lot of security analysts and engineers once did. It even can write NGINX config scripts, which is something nobody can successfully do. (Yes, that’s a nerdy joke.)

AI can also do a lot of the grunt work industry analysts do, as Richard Stiennon has proved with his IT Harvest platform.

None of this is good news for job seekers. While the cratering US economy accounts for a lot the downsizing, AI is only making it worse. AI will never entirely replace humans, but organizations are testing the limits of that. Teams are being shrunk, and the remaining staff is expected to fill the gaps with AI tools.

This adds up to a bleak outlook for security staffing in 2026.

6. Cloud Eats Security

However, the ultimate prediction for 2026 is that security is everywhere, integrated into everything. In 2021, I identified a growing cybersecurity trend: Cloud Eats Security (also called “platformization”.) Cloud providers, like AWS, Azure, and GCP, and SaaS providers like Salesforce or ServiceNow, were (are) slowly consuming many of the traditional security capabilities (firewall, intrusion detection, vulnerability management, web-application firewalls, etc.)

The impact of this trend is that security is now integrated into the platforms companies use. Companies do not need to purchase individual point-solutions which demand complex and expensive integration efforts. However, even the point solutions are getting on board with this trend, making their products much simpler to roll out and fully integrated into cloud and SaaS offerings.

This was one of the reasons why Google paid $32B for Wiz in 2025. Wiz is a powerful platform that simplifies a lot of cloud security functions. Cloud security providers, like Cloudflare, are also rolling out new capabilities practically everyday. And some of those are free, such as Cloudflare Tunnels which allows anybody to securely host anything on the Internet.

To help monitor all these integrated systems, there are emerging AI-powered security operations products from companies such as AI Strike, Torq, and Dropzone AI.

If all this AI stuff seems unstoppable, and wildly insecure, well, it is. However, there are promising emerging technologies such as Automated Moving Target Defense.

And the final piece of this trend is the rise of automated, integrated managed security providers who can keep an eye on everything. In early 2025, I worked on an MSSP analysis project. I was stunned at how many MSSPs had fully embraced automation, AI, and the cloud in their offerings. Unless your organization is gigantic or a government agency, there is no reason to do security internally. Hire an MSSP. There are a lot of great ones out there that can further simplify security.

Conclusion

For 2026, I predict cybersecurity will continue down the path of more integration, more platformization, and more simplicity. This will not stop attackers, but it does swing the odds of success toward the defenders.

As for the attackers, like the rest of us, they are going to use AI to do their dirty work. And like the rest of us, they are going to generate a lot of pictures of cats playing pickleball. Which means defenders do not need some whiz-bang quantum oscillating over-thruster to stop them. They merely need to make the most of the security tools they already have.

NOTE: The companies mentioned in this blog are for examples only. I received no compensation for mentioning them nor do I endorse them or their technologies. 

The post 2026 Cybersecurity Predictions appeared first on Zenaciti.

Consider something as common as television. For decades, there were only 3 channels with limited content. This was because broadcasting TV signals was expensive and highly specialized. In the 1980s, cable TV standardized the transmission of signals over coaxial and fiber cables, unleashing innovation and deregulation. Today, we have hundreds of channels and vast choice. Standardization (as well as technology improvements) made that happen.

From shipping containers to application containers, standardization is a necessity for innovation and scale.  

Non-Standard Security

For all the innovation in information security, there is little to no standardization.  There are some technical standards, like STIX and TAXII for intelligence sharing.  However, these are limited in their scope.  Security has no standards to govern the configuration, documentation, and auditing of security controls. This is where all the problems live. 

Now, you may think that compliance standards, like PCI or FedRAMP provide a standardized way to implement security. Yeah, no. Compliance frameworks describe an ideal state in generic terms.  Compliance tells you that you must have a control, it does nothing to help you deploy, configure, manage, or audit that control.  Furthermore, it is (relatively) easy for an organization to skirt around compliance requirements and still pass an audit. This is because audits remain a subjective assessment from a person.  

The sheer vastness of the security technology universe also complicates standardization .  Take a moment and visualize the vendor expo at RSA Conference or BlackHat. What you see are thousands of security vendors. Yet, each vendor only solves a fraction of an organization’s security needs.  SIEM vendors focus on logs and analysis needs, endpoint security defends against ransomware and viruses, GRC vendors create work for people. Each vendor only plays one part in an organization’s entire security program.  Nothing holds this mess together.  

What we have is a chaotic mess of security tech with no standardized way to configure and validate security controls. Consequently, security is entrusted to people who make mistakes and vendors who have agendas. 

This mess has real world implications, namely breaches.  The root cause in every breach is misconfigured or missing security controls (which ultimately is human error).  The recent Colonial Pipeline attack was the result of attackers stealing a single password to a dormant VPN account.  Multi-factor authentication, robust network malware, stronger endpoint controls, and zero trust access would have all worked to stop this ransomware attack cold.  However, those controls either did not exist or were not configured properly. There is probably some former security person from Colonial Pipeline furiously posting to Twitter: “I warned them this would happen, but they ignored me!!!” 

If there was a standard way to implement, configure, and validate security, then an organization like Colonial Pipeline could have implemented all these appropriate controls without depending on people to do it correctly (which they obviously did not).  They could simply follow a script. 

However, I am not suggesting eliminating or consolidating all those security technologies.  Rather, I am suggesting a standardized way to configure and validate security controls. Or in other words, a universal “language” that abstracts the configuration, validation, and documentation of security controls from specific vendor tools.   This is similar to how Hashicorp’s Terraform, AWS’s Cloudformation, or RedHat’s Ansible work.  These are languages (or platforms) that build and configure cloud services and infrastructure.  While they can play a part in security, they are not specifically for security.   

So, why not a security language?  Let’s take a look at what this language could be. 

Introducing SeCON?   

For lack of a better name, we can call this proposed language SeCON (security configuration object notation.)  At least until somebody comes up with a better name. 

So what would this “SeCON” language do? 

• Define a Dictionary of Security Controls:  SeCON would establish a standard set of security controls that any organization can use, such as endpoint security, firewalls, SIEMs, vulnerability scanners, and so forth. 
• Configuration: It would have a common way to define how a security control is setup and configured.  Things like IP address, DNS names, authentication methods, and certificates. 
• Policies:  It would have a common language to define policies for security controls.  For example, it could have a native set of firewall, routing, and scanning type policies.  Since this may not be sufficient for the universe of security tools, it could also offer a way to embed native configuration language. This would allow the language to accommodate the unique policy or configuration aspects of each tool.    
• Documentation:  SeCON would also provide a method to document the control’s configuration.  In the same structure where configuration and policies are defined, there would be text structures to attach how the control is configured and why. 
• Testing: Lastly, there would be a way to read a configuration file and then test a specific instance of a control to see if it meets the configuration parameters.  This provides a “closed loop” system where the same language that configures a tool, also has the power to validate that configuration at a later date.   

More Barriers

Obviously, this standardized security language would have some significant hurdles to overcome.  Here are a few to consider.   

• Adoption:  Vendors would need to adopt their products to accommodate this language.  However, if a vendor publishes an API, then it would be relatively simple to map the language to specific API commands. 
• Platform: SeCON would need some platform that can execute all these rules and commands.  Ideally, cloud vendors, like AWS could adopt this language into their existing scripting languages like CloudFormation.  However, I am sure there are some technical details I am not considering that may make this difficult.
• Resources:  Standards such as this require a lot of work to define, build, and promote.  To make this a reality would take money and backing.  Support from cloud service providers or standards bodies like NIST would be critical to success.
• Complexity:  This is stating the obvious, but security is complex.  Its not as simple as provisioning a virtual machine or a container.  It is this complexity that makes a language like this necessary. 

The Promise of SeCON

I admit, this language is merely an idea…and possibly an outlandish one.  However, I remain a firm believer that the root cause of all security problems is configuration.  Ransomware attacks are successful not because their malware is particularly innovative.  Rather, organizations continue to rest the security of their company on the inconsistencies and inadequacies of people.  If we can close that gap, it will become more difficult to exploit vulnerabilities because there will be fewer of them in the first place. 

The promise of a standardized language for security would also mean decoupling security configurations from the idiosyncrasies of each platform.  It would not matter whether you had a Fortinet or a Palo Alto, McAfee or Crowdstrike.  If they all worked with the same language, you could standardize across them all.  This would give you, as a user of those technologies, greater freedom to change to a different technology without the arduous cut over from the old tech to the new one.  This is no different than how technologies use Bluetooth, TLS, or NTFS.  It does not matter what brand of tech you have.  They all conform to the same standards. 

The real benefit is the standardization itself.  Once security is standardized, it can be applied universally, consistently, and deviations detected quickly.  Using a single tool, you could theoretically deploy, configure, monitor, manage, and document your security infrastructure.  As your enterprise expands, you can use the same standardized language to modify your security infrastructure. 

A standard security language could deliver massive scale while improving the consistency of security controls. 

Conclusion

If security is ever going to get ahead of the threats, we must stop twiddling knobs and relying on humans to configure everything properly.  A standard security language could revolutionize how security is applied and managed.  It could finally make sense of the messy vendor space. 

What do you think?  What am I missing?  Share your feedback here, or you can always email me at andrew.plato@zenaciti.com.  

The post Standardizing Security appeared first on Zenaciti.