Happy 2026! The new year is a fresh start for everyone, and many of us use this time to set goals, make plans and focus on what we can do to improve our lives. This is true for security professionals as well. Here are some things to keep in mind when planning to shore up your application security defenses in 2026!

Don't be on the naughty NIST!

Christmas is over, but that doesn't mean you are safe from being on the naughty passwords list. Most of my fellow penetration testers are saddened to find some of the same bad passwords in client environments that we've been finding since starting our careers. People often choose weak passwords and then subsequently choose slight variations to said bad passwords when forced to update. For example, someone with the password Goblue123! may pick Goblue321@ at the next forced password reset. The tendency for people to reuse bad passwords instead of using a password manager means that, too often, attackers are able to pull a password from a data breach dump file of bad passwords, and then use it to gain access to personal or work environments.

Execute Order SP 800-63B-4

For years, the go-to guidance for passwords has been the National Institute for Standards and Technology (NIST) Special Publication 800-63B, Digital Identity Guidelines. That's quite the mouthful. Before July of last year, NIST and OWASP guidance resulted in many organizations creating password policies that allowed weak eight-character passwords. While these eight-character passwords were "compliant" with NIST and OWASP guidance, they were not strong enough to protect the organization from dictionary-based login attacks that leveraged large dictionaries of passwords pulled from data breaches, like rockyou.txt and its descendants. As a fun exercise, check out the How Secure is My Password Tool and try to create an eight-character password that would take longer than two days to crack.

In July 2025, an overdue (in my opinion) shift occurred. NIST SP 800-63B-4 Section 3.1.1.2 updated the latest guidance around password lengths. Going forward, NIST encourages organizations to implement a password policy that requires:

• A 15-character minimum password length for accounts without multi-factor authentication enabled
• An eight-character minimum password length for accounts that have multi-factor authentication enabled

OWASP has also updated their password length guidance accordingly to reflect this. Multi-factor authentication's merit as a strong layer of defense-in-depth has been well documented. Organizations that insist on keeping an eight-character minimum password can do so by implementing multi-factor authentication across the organization. Organizations that wish to continue using single-factor password-based authentication will need to update their password policies to require the 15-character password length. 

While this change should have a large, positive impact to the security culture of organizations en masse, its rollout will take time and will likely result in growing pains for employees that have been used to the convenience of shorter passwords for their entire careers. Unfortunately, the majority of the web application penetration tests I've performed since the update include a "Weak Password Policy" finding to reflect the change. Organizations can help with the adoption by highlighting some of the high-impact data breaches resulting from a weak password policy and missing multi-factor authentication. Sadly, there are many to choose from:

• Former SolarWinds CEO blames intern for ‘solarwinds123’ password leak
• Federal government investigating multiple hacks of US water utilities
• McDonald’s hiring platform exposes 64M job applications

Don’t Get Stung in 2026: Mind The OWASP Top 10: 2025

One great marker of trends in application security is the OWASP Top 10 list. This past August, OWASP released the latest update to the list. The last update was back in 2021. The new list continues the trend that's been underway for several iterations to its ultimate destination, replacing individual vulnerabilities with more broad categories. For example, Server Side Request Forgery (SSRF), which was previously No. 10 on the 2021 list, has been migrated to the Broken Access Control category, which holds its position at No. 1 on this year's list. This is similar to how Cross-Site Scripting (XSS), which was No. 7 on the 2017 list, was rolled into the more broad "Injection" category; No. 3 on the 2021 list. In addition to the change in the aforementioned password guidance update, there are some other notable changes that organizations should be aware of.

To Avoid Pain, Secure Your Supply Chain

2021's "Vulnerable and Outdated Components" category has been changed to "Software Supply Chain Failures." This reflects more than just a name change. The 2021 category was made to address the prevalence of CVEs (known security vulnerabilities) in components of code in an organization's environment. Unfortunately, this problem is still very prevalent. 2025 ended with two particularly concerning, high-risk vulnerabilities. A remote code execution bug affecting react.js and next.js users, CVE-2025-551282 a.k.a React2Shell, and a vulnerability that allows an attacker to access sensitive portions of memory in MongoDB instances, CVE-2025-14847 a.k.a. MongoBleed. React2Shell has the rare distinction of a Common Vulnerability Score System (CVSS) "perfect" score of 10.0 — the most severe rating that a vulnerability can get.

The name change reflects an encouragement from OWASP to DevSecOps professionals to be proactive in configuring tooling that enables quick detection and response when vulnerabilities in the software they rely on are discovered. Combining tools like Dependabot with a strong vulnerability management program allows defenders to patch and update before attackers are able to break in.

Don’t Accept Exceptional Conditions

A new category was introduced on the 2025 list, and although it's No. 10, it still merits taking seriously. The "Mishandling of Exceptional Conditions" refers to an application that fails "to prevent, detect, and respond to unusual and unpredictable situations, which leads to crashes, unexpected behavior, and sometimes vulnerabilities." Consider the example of the Australian Commonwealth Bank ATM "glitch" from 2011. ATMs that couldn't successfully identify the correct account balance of customers due to a connection error instead operated in a "stand-by" mode, continuing to disburse funds even if the account didn’t have them. This is an example of "failing open," where an application errors in a way that allows an attacker to bypass security protections that should be in place. This would be analogous to walking up to a digital keypad next to a building's entrance and performing an action that the developers may not have accounted for, like holding down the "1" key indefinitely in the hopes that the application will “error out.” If this error causes the door to open, you have discovered a "fail-open" vulnerability.

In the past, these types of poor exception handling haven't fit neatly into other OWASP Top 10 categories, but on the 2025 list, they finally have a home. The principle takeaway for developers is to ensure that proper exception handling is in place. This category is near and dear to my heart, since I started my career in tech as a Quality Assurance tester. Good QA testing can help identify instances of improper exception handling. Developers and QA engineers should work together to ensure that untrusted inputs sent from the client match the expected format and properly handle exceptions when they don't.

Leverage (Artificial) Intelligence To Get (Genuine) Results

I would be remiss if I didn't mention artificial intelligence, and I would also miss vital appeals to the search engine optimization bots. Information security professionals are very busy creating, testing and improving AI tooling. New tools will no doubt increase the speed and thoroughness of application testing. In its most recent releases, Burp Suite, Portswigger’s web interception proxy that I use to perform most web application penetration test cases, integrated several AI-based optimizations. With the click of a button, penetration testers can launch an AI-based task targeted at a single anomaly or possible vulnerability. While this feature comes at a cost, it has great potential to aid penetration testers in proving out false positives and properly assessing the impact of legitimate findings. No doubt AI-enabled tools will help those on blue teams more efficiently harden their DevSecOps pipelines as well.

‍

2026 will be an exciting year for all of us. If you're looking to level up your application security, consider partnering with NetWorks Group.

‍

Published By: Josh Gatka, Senior Ethical Hacker, Application Security Specialist, NetWorks Group

Publish Date: January 15, 2026