Ivanti Blog: Security

Trusted Ownership: How Ivanti Application Control scales beyond allowlisting

Wed, 25 Feb 2026 14:25:15 Z

Application control is one of those security topics where many people carry old assumptions. Traditional allowlisting feels safe but quickly becomes a maintenance burden. Blocklisting feels reactive and incomplete. And while tools like Microsoft AppLocker led many to believe that strict allowlisting is the gold standard, modern attacks have proven otherwise. Attackers increasingly rely on legitimate, signed tools — used in the wrong context — to bypass list-based controls entirely.

So when organizations evaluate Ivanti Application Control or Ivanti Neurons for App Control and encounter Trusted Ownership, it may initially resemble blocklisting because explicit blocks are possible. In reality, Trusted Ownership is a far broader and far lighter operationally inspired‑ enforcement model that controls execution based on origin, not just identity.

Instead of managing expanding lists, it enforces security on who has placed software on the system, aligning cleanly with modern software distribution practices and zero trust principles. It’s best understood not as another list mechanism, but as a provenance inspired enforcement model that controls execution based on origin, not just identity.

That shift in thinking leads to a better question for modern application control: not only what a file is, but how it got there.

Beyond lists: why provenance control now matters

The question of how a file arrived on the system is at the core of provenance control. Instead of trusting files based on publisher, path or hash alone, provenance control evaluates the origin and process that introduced them. Who wrote the file to disk? Through which mechanism? Did the installation follow a controlled IT workflow? This evaluation shifts application control from object trust to process trust, creating a far stronger security boundary.

In Ivanti Application Control, provenance control is implemented as Trusted Ownership. Any file placed by a trusted owner is allowed; anything introduced by a user is denied by default. This applies consistently across executables, DLLs, installers and scripts. Because identities like SYSTEM, TrustedInstaller and Administrators are trusted by default, software delivered through standard deployment channels such as MS Intune, MECM, Ivanti Endpoint Manager (EPM)or other enterprise tools runs immediately without rule maintenance or exceptions.

This marks a fundamental break from classic allowlisting. AppLocker rules live or die based on exact publisher, path or hash definitions. It doesn't evaluate installation origin and doesn't automatically trust your deployment mechanisms. Software delivered by Intune still requires a preexisting allow rule, often relying on broad defaults that permit the Program Files or Windows directories.

That distinction matters because modern attacks increasingly weaponize legitimate tools in improper contexts. Provenance control neutralizes much of that risk by enforcing trust in how software arrives, not just what it is. It aligns with zero trust principles, reduces supply chain exposure, and dramatically narrows opportunities for Living off the Land (LotL) abuse by default.

Once you understand the importance of origin, the next question becomes: how do you enforce it at scale?

The answer: apply provenance consistently across all the ways software executes and all the ways it is delivered.

Beyond Blocklists: Broad coverage built for modern software deployment

Provenance control shifts application security away from managing endless lists and toward validating the process by which software arrives on the system. Once you adopt this perspective, it becomes clear that Trusted Ownership is not a blocklist approach. It's an origin-based trust boundary that behaves very differently from traditional allowlisting.

A common misconception is that Trusted Ownership resembles blocklisting because administrators sometimes add targeted deny rules for well-known Windows tools. In practice, these deny rules are defensive hardening measures against Living off the Land techniques. Every serious application control method uses such targeted restrictions. The core of Trusted Ownership is the opposite of blocklisting. Software delivered through a controlled and trusted process is permitted by default, while user-introduced content is denied by default.

A more important differentiator is coverage. Many organizations that rely on classic allowlists end up focusing almost entirely on executable files. They often avoid applying the same enforcement to DLLs, scripts and MSI packages because these file types make rule maintenance far more complex. This creates gaps that modern attackers frequently exploit.

Trusted Ownership avoids these gaps by applying the same origin-based enforcement to the full execution chain. Executables, DLLs, scripts, MSI installers and related components are evaluated through the same trust model. Because trust is determined by who introduced the file, you do not need separate policies for each file type. A script in the Downloads folder, a DLL created in a temporary build directory or an EXE executed from a user profile all receive the same default deny treatment when they originate outside a controlled installation process.

This trust model also aligns naturally with how modern endpoint management platforms deliver software. Solutions such as Intune, MECM, Ivanti Neurons for MDM, Ivanti Endpoint Manager and similar systems typically install applications using the SYSTEM identity or another trusted service account.

Since these identities are already Trusted Owners, software deployed through these channels runs immediately without creating allow rules, maintaining file paths or updating policies. Only when you intentionally use alternative installation accounts, such as custom DevOps agents or scripted installations in user context, do you need to identify that identity as a Trusted Owner.

The result is a model with broad and consistent coverage across all relevant file types. It works seamlessly with modern software distributions and avoids the operational overhead associated with classic allowlists that focus mainly on executable files.

Trusted Ownership places trust not in individual objects but in the controlled processes through which software is delivered, creating a more scalable and more secure approach to application control.

Where WDAC (App Control for Business) fits in

Microsoft maintains two application control technologies: AppLocker and App Control for Business (formerly WDAC). Although both still exist, Microsoft is clear about their roles. AppLocker helps prevent users from running unapproved applications, but it does not meet the servicing criteria for modern security features and is therefore categorized as a defense-in-depth mechanism rather than a strategic security control.

Microsoft’s forward path for application control is App Control for Business and explicitly states that AppLocker is feature-complete and no longer under active development, beyond essential security updates. This means all new capabilities are delivered only in WDAC and not in AppLocker.

App Control for Business introduces the Managed Installer concept. This allows Windows to automatically trust applications installed through designated deployment platforms such as Intune or MECM. Trust is derived from the distribution channel rather than individual files, reducing rule maintenance significantly.

This aligns closely with Ivanti Application Control’s Trusted Ownership model. Both approaches trust software based on the controlled process that installed it rather than on discrete file attributes. However, Trusted Ownership applies this concept in a simpler and more operationally accessible way. Ivanti trusts identities such as SYSTEM and designated service accounts without requiring complex policy layers, XML definitions or deep WDAC expertise.

Ivanti hears from many organizations that they struggle to operationalize WDAC. WDAC policies require careful design, lengthy testing in audit mode, driver and kernel exception management and ongoing maintenance of multiple policy sets. This often leads organizations to combine WDAC with AppLocker to cover both low-level enforcement and day-to-day user space control and end up with administrative overhead.

Ivanti Application Control offers a unified alternative. Through Trusted Ownership, Trusted Vendors and digital signature validation, it delivers a provenance-based default deny model with consistent coverage across executables, DLLs, scripts and MSI packages.

Instead of maintaining two MS control planes with different scopes, organizations manage a single, streamlined policy that enforces trust based on how software is introduced into the system. This provides many of the practical goals customers attempt to achieve with a combined WDAC and AppLocker deployment, but with lower operational complexity and one cohesive trust model.

LOLBins and argument-level control

With broad coverage established, the issue then becomes how to handle the legitimate tools already on every machine that attackers like to abuse.

Modern attackers often avoid using traditional malware and instead rely on the tools already present on every Windows device. These Living off the Land tools (LOLBins) are legitimate and necessary for normal operations, which makes them difficult to block without affecting productivity. Traditional allowlisting struggles here because broad blocking breaks workflows, while broad allowing leaves dangerous gaps.

A provenance-based model such as Trusted Ownership changes this dynamic. Even if an attacker attempts to use a built-in tool, the content they try to run usually does not come from a trusted installation process. Since Ivanti evaluates the origin of that content, most misuse attempts fail automatically. The tool may be legitimate, but the content it is asked to run is not, and Trusted Ownership stops it before it executes.

It is also important to understand not only which tools run but what they are being asked to do. Many interpreters and runtimes, such as PowerShell, Python, or Java, can be perfectly safe in one context and risky in another. A business application may rely on Java to start a specific, approved process, while a user downloaded JAR file is an entirely different scenario.

Ivanti handles this through a layered approach. A JAR file is first evaluated using Trusted Ownership, which blocks it immediately if it was introduced by a user rather than through a controlled deployment process. Beyond that, administrators can create simple allow rules that specify exactly which Java commands are permitted, ensuring that only legitimate Java based applications run while attempts to launch unapproved JAR files are quietly denied.

The same principle applies across other tools as well. Policies can approve the exact behavior your organization needs while blocking activities that fall outside those boundaries. This avoids broad, brittle rules and keeps daily work running smoothly.

The result is a balanced and modern approach. Trusted Ownership stops untrusted content by default. Focused hardening aligns with government and community best practices for reducing living off the land abuse and intent aware controls ensure that legitimate processes continue to function without opening doors for attackers.

This approach closely aligns with current community and government guidance on mitigating living off the land techniques. Agencies such as CISA, NSA, FBI and the Australian Cyber Security Centre emphasize reducing opportunities for attackers to use built-in tools by controlling how they are used and restricting the untrusted content they act upon. Their joint guidance highlights that LOTL attacks depend on abusing native tools and stresses the need for controls that limit this misuse without blocking legitimate system processes.

Ivanti’s model reflects this guidance. Trusted Ownership automatically blocks the untrusted content that attackers rely on, while a small number of focused restrictions address the small set of tools that require extra care.

Trusted Ownership in action: Real-world scenarios

Here are a few operational examples of how Ivanti Application Control and Trusted Ownership work in practice.

A portable application is copied into the user profile. Ivanti blocks it because it is user-owned. AppLocker only blocks if there are matching rules. Without the right path or publisher rules, the behavior can differ.
An email attachment launches a PowerShell script from Downloads. Ivanti denies it because of user ownership. AppLocker depends on script rules and, on block events, forces PowerShell into Constrained Language Mode, which will still run the script.
Abuse of OS tools such as rundll32 or mshta. Both models need targeted deny hardening. Ivanti combines this with provenance control which generally reduces the number of exceptions you need. AppLocker relies on curated deny sets and requires periodic tuning.
A vendor update ships new signed files. Ivanti allows the update when it arrives via the trusted deployment channel due to Trusted Ownership. AppLocker can accommodate this with publisher rules, but signature reuse across multiple products or unusual install paths often leads to extra maintenance and broader trust than intended.
A user downloads a JAR and tries to run it with Java. Ivanti blocks the attempt because the JAR is user-introduced and fails Trusted Ownership. If needed, admins can allow only the exact approved invocation by matching the full command line. AppLocker cannot match arguments and relies on publisher, path or hash rules.

Conclusion

Provenance control shifts application control from a management problem to a trust model. Instead of trusting individual files, it trusts the process by which software arrives on a system, making security both scalable and workable.

Trusted Ownership fits squarely into this approach. It is neither a blocklist nor a classic allowlist, but a model where software that arrives through a controlled IT process is allowed by default, while everything outside that process is denied by default. By enforcing on origin and ownership rather than on ad hoc files, Ivanti Application Control and Ivanti Neurons for App Control align far better with modern attack techniques and today’s software distribution.

If you keep treating application control as a list management exercise, you will feel the administrative burden. If you treat it as a trust boundary, you gain scalability, security, and operational workability.

How CEOs Want CISOs to Communicate Cybersecurity Risk Management Strategy

Tue, 17 Feb 2026 13:00:01 Z

Most CEOs can recite their quarterly benchmarks and revenue down to the decimal point, but ask them about their organization's cyber risk exposure, and the answers become more vague. It's not that today’s CEOs don’t care about security — cybersecurity ranks among the top concerns for boards and executive teams. The problem runs deeper: a fundamental breakdown in how security risks are explained to business leaders that overlooks the impacts on their business outcomes.

Lack of competence is not the cause of most communication issues between CISOs and CEOs. They stem from a familiar problem: the curse of knowledge. The curse of knowledge is a common challenge where experts — in this case security leaders — might assume that everyone in the room has a baseline understanding of technical information and terminology, so they fail to break down complex risks into plain language and elaborate on real-world context.

Ivanti’s 2026 State of Cybersecurity Report underscores this disconnect. Nearly six in 10 security professionals say their teams are only moderately effective at communicating risk exposure to executive leadership.

When CEOs and CISOs don’t speak the same language, critical business vulnerabilities can be obscured by technical jargon. When communication breaks down, organizations waste time and money on misdirected investments while gaps in protection go unnoticed until a breach forces the conversation.

With threat levels rising, AI-enabled attacks are becoming more sophisticated, and data breaches make headlines weekly. The stakes for clear communication between CISOs and executive leadership have never been higher.

To understand why this communication gap persists, we need to examine both the fundamental challenges and the metrics being used to measure success.

Why cyber risk communication fails: the curse of knowledge

That disconnect between CEOs and CISOs isn’t caused by a lack of data. If anything, it’s the opposite. From the CEO's seat, the challenge isn’t attention or intent. Rather, it’s seeing dashboards, metrics, acronyms and severity scores without understanding the impact of these results on the whole business.

Security leaders need to assume that many in the room don’t understand the implications of terms like CVSS scores, attack surfaces and zero-day vulnerabilities. CEOs want more than dashboards filled with metrics, acronyms and severity scores.

Cybersecurity briefings need to go a step further and demonstrate the financial, legal, and reputational implications of these results for the business. A CISO might report "587 critical vulnerabilities detected this month" when what the CEO actually needs to know is: "Which of these threaten our ability to serve customers and what's our plan to address them?"

Cybersecurity KPIs that matter to CEOs

Useful KPIs clearly connect vulnerability management efforts to business risk. However, our cybersecurity research finds that the most used KPIs used by security teams fail to reflect risk context.

Currently, only half of companies (51%) track cybersecurity exposure scores or other risk-based indexes. Many security teams still rely on process metrics such as mean time to remediate (47%) or percentage of exposures remediated (41%).

Metrics like MTTR, patch velocity and percentage remediated matter to security teams, but they measure operational efficiency, not business exposure or potential financial impact. In isolation, they can look reassuring while obscuring the real question: are we managing our risk effectively?

These metrics, which focus on speed and coverage, may look positive on their own, but don’t do much to show whether current remediation efforts actually improve risk posture. It matters less how quickly vulnerabilities are remediated and how many are addressed. What matters more is whether the right problems are being addressed.

Shared understanding between security teams and the board and C-Suite requires grounding inscrutable metrics in real-life stakes. For CEOs, this means aligning with your CISO on the most important risks to your specific organization — are you a financial institution that frequently faces sophisticated fraud schemes, strict compliance requirements like PCI-DSS and SOX and the constant threat of ransomware targeting customer financial data? Are you a healthcare organization grappling with securing an expanding network of connected medical devices while maintaining rigorous compliance standards to protect sensitive patient data?

Let’s illustrate the difference between an executive security briefing that relies only on technical metrics vs. one that adds context and business impact.

What the CISO says:

"We discovered 11,000 vulnerabilities.”
"MTTR is down to 15 days from 25 days."
"We achieved an 88% remediation rate on critical CVEs."

What the CEO actually needs to know:

"We’ve identified ten critical vulnerabilities that could impact revenue-generating systems."
"If attacked today, we can restore critical operations in six hours compared to 48 hours last year."
"This protection enables us to pursue EU expansion without additional compliance risk."

Building an executive-level risk appetite framework

Executive communication depends on shared frameworks and a common point of reference for how risk is defined, measured and discussed. To eliminate inconsistencies and confusion, all stakeholders should be involved in creating and enforcing a risk appetite framework.

A major goal of these conversations is helping business leaders understand that the goal of the cybersecurity program isn't to be completely “risk free” — it’s impossible for any modern organization to become completely risk free. In other words, CEOs must be able to distinguish between their risk appetite and risk posture.

1. Risk appetite: how much risk their business is currently willing to tolerate in pursuit of its overarching goals.

2. Risk posture: the reality of the organization’s current risk exposure.

Most organizations now recognize the need to formalize how much cyber risk they’re willing to accept. Ivanti’s research shows more than 80% of organizations have a documented risk appetite framework.

However, fewer than half of the organizations say these frameworks are closely followed in day-to-day operations. When frameworks exist on paper but don't guide actual decisions, it is highly likely that your organization’s risk appetite and risk posture are not aligned.

How exposure management bridges the communication gap

Exposure management is a risk-based approach that continuously identifies, prioritizes and validates the scope of potential threats across the entire attack surface. Practicing exposure management helps unite security and executive leaders around a single, comprehensive strategy that reorients cybersecurity around business-critical risk.

Instead of treating all vulnerabilities as equal, exposure management focuses on identifying and prioritizing the organization's highest risks by asking:

Which current exposures are threat actors exploiting in the wild?
Which assets need to be prioritized based on current business operations?
Which assets, if compromised, would have the greatest impact in terms of reputational, customer, or legal damages?

Ivanti’s research report shows that nearly two-thirds of organizations now invest in exposure management, and leadership understanding has increased year over-year. But execution still lags: Only about a quarter of organizations rate their ability to assess risk exposure as excellent.

To close that gap and operationalize exposure management effectively, CISOs should anchor executive communication around three principles

1. Translate technical signals into business context. Instead of reporting vulnerability counts, explain which exposures affect revenue-generating systems, customer data or regulated environments.

2. Prioritize emerging threats by impact, not volume. Executives don’t need to track every new attack technique. They need to understand which situations could materially disrupt the business and how prepared the organization is to respond.

3. Use scenarios, not spreadsheets. Narratives that connect cause, impact and outcome, backed by data, help leaders internalize risk and make faster decisions.

This approach shifts your risk mitigation strategy from reactive defense to proactive decision-making.

The path forward

When executives and security leaders speak the same language, the curse of knowledge can be broken and cybersecurity becomes a strategic enabler that protects business value, enables growth and turns security strength into competitive advantage.

The curse of knowledge can be broken — one translated metric, one business-focused conversation, and one clear decision at a time.

February 2026 Patch Tuesday

Tue, 10 Feb 2026 21:58:44 Z

February Patch Tuesday includes recent out-of-band updates from Microsoft between January 17th and 29th, including multiple bug fixes and a fix for a zero-day exploit in Microsoft Office. In addition, Microsoft announced the phased disablement of NTLM precede the February 2026 Patch Tuesday release.

For the February Patch Tuesday release, Microsoft has resolved 57 unique CVEs. Six CVEs are flagged as Exploited and three of those are Publicly Disclosed as well. Add the out-of-band (OOB) zero-day and you have a lineup of CVEs that need some attention.

January Out-of-Band Releases

The first OOB release on January 17th resolved a credential prompt failure when attempting remote desktop or remote appliance connections. The second round of OOB updates occurred on January 24th and 26th resolving application crashes in Outlook and OneDrive, and system hibernation/shut down issues. And finally, the third OOB update on January 26th was a zero-day vulnerability CVE-2026-21509, a Microsoft Office Security Feature bypass vulnerability.

Microsoft plans phased NTLM disablement

Microsoft released their plan for the phased disablement of New Technology LAN Manager (NTLM) in the latest operating systems starting now in 2026 and beyond. The NTLM authentication protocol was introduced back in 1993 and has since been superseded by Kerberos protocols, which are far more secure. However, NTLM has remained the fallback when Kerberos is unavailable despite being deprecated and having weak algorithms.

Phase one introduces additional auditing to help identify where NTLM may still be running and changing it out where you can. Starting now, Microsoft recommends using advanced NTLM auditing already available in Server 2025, and Windows 11 24H2 and newer. Phase two begins with major OS updates coming later this year. This update will address the ‘pain points’ or blockers by removing multiple fallback scenarios where Kerberos reverts back to NTLM.

And finally in phase three, NTLM will be disabled by default. The code will still be there, but you will need to explicitly re-enable it if absolutely needed. This three-phase approach will happen quickly, so plan appropriately to replace NTLM in your environment and take a giant security step forward. The ‘NTLM disabled by default’ phase will occur with the next major Server update.

Microsoft’s exploited vulnerability 

On January 29th, Microsoft resolved a Security Feature Bypass vulnerability in Microsoft Office (CVE-2026-21509). The vulnerability is rated Important by Microsoft and has a CVSS v3.1 score of 7.8, but it has been confirmed to be exploited in the wild. An attacker can send a user a malicious Office file and convince them to open the file to exploit the vulnerability. A risk-based prioritization methodology warrants treating this vulnerability as a higher severity than the vendor rating or CVSS score assigned.

Microsoft resolved an Elevation of Privilege vulnerability in Remote Desktop Services (CVE-2026-21533). The vulnerability is rated Important by Microsoft and has a CVSS v3.1 score of 7.8, but it has been confirmed to be exploited in the wild. An attacker who successfully exploited this vulnerability could gain SYSTEM privileges. The vulnerability affects Windows 10 and later editions of the OS. A risk-based prioritization methodology warrants treating this vulnerability as a higher severity than the vendor rating or CVSS score assigned.

Microsoft resolved an Elevation of Privilege vulnerability in Desktop Window Manager (CVE-2026-21519). The vulnerability is rated Important by Microsoft and has a CVSS v3.1 score of 7.8, but it has been confirmed to be exploited in the wild. An attacker who successfully exploited this vulnerability could gain SYSTEM privileges. The vulnerability affects all currently supported and ESU supported versions of Windows OS. A risk-based prioritization methodology warrants treating this vulnerability as a higher severity than the vendor rating or CVSS score assigned.

Microsoft resolved a Security Feature Bypass vulnerability in MSHTML Framework (CVE-2026-21513). The vulnerability is rated Important by Microsoft and has a CVSS v3.1 score of 8.8, but it has been confirmed to be exploited in the wild. An attacker who successfully exploited this vulnerability could bypass a security feature over a network. The vulnerability affects Windows 10 and later editions of the OS. A risk-based prioritization methodology warrants treating this vulnerability as a higher severity than the vendor rating or CVSS score assigned.

Microsoft resolved a Security Feature Bypass vulnerability in Windows Shell (CVE-2026-21510). The vulnerability is rated Important by Microsoft and has a CVSS v3.1 score of 8.8, but it has been confirmed to be exploited in the wild. An attacker who successfully exploited this vulnerability could bypass a security feature over a network. The vulnerability affects all currently supported and ESU supported versions of Windows OS. A risk-based prioritization methodology warrants treating this vulnerability as a higher severity than the vendor rating or CVSS score assigned.

Microsoft resolved an Security Feature Bypass vulnerability in Microsoft Word (CVE-2026-21514). The vulnerability is rated Important by Microsoft and has a CVSS v3.1 score of 7.8, but it has been confirmed to be exploited in the wild. An attacker can bypass a security feature locally due to a reliance on untrusted inputs. A risk-based prioritization methodology warrants treating this vulnerability as a higher severity than the vendor rating or CVSS score assigned.

Microsoft resolved a Denial of Service vulnerability in Windows Remote Access Connection Manager (CVE-2026-21525). The vulnerability is rated Moderate by Microsoft and has a CVSS v3.1 score of 6.2, but it has been confirmed to be exploited in the wild. A null pointer dereference in Windows Remote Access Connection Manager allows an unauthorized attacker to deny service locally. The vulnerability affects all currently supported and ESU supported versions of Windows OS. A risk-based prioritization methodology warrants treating this vulnerability as a higher severity than the vendor rating or CVSS score assigned.

Ivanti security advisories 

Ivanti has released one security update for February. The update affects Ivanti Endpoint Manager and resolves two new CVEs and 11 medium severity CVEs that were disclosed in late 2025. More details and information about mitigations can be found in the February Security Advisory.

In addition, there was a security advisory on January 29th for Ivanti Endpoint Manager Mobile (EPMM) that had a limited number of customers impacted at time of disclosure. Ivanti urges all customers using the on-prem EPMM product to promptly install the Security Update. The security advisory, additional technical analysis, and an Exploitation Detection script co-developed with NCSC-NL can be found in the January Security Advisory.

Third-party vulnerabilities  

Adobe has released nine updates this month resolving 43 CVEs, 27 of which are Critical. All nine updates are rated Priority three by Adobe.

February update to-do list

Windows OS and Microsoft Office updates are priority this month resolving six new and one OOB zero-day exploits.

Review Microsoft phased disablement of NTLM announcement and documentation to start planning for the deprecation and disablement of NTLM.

Exposure Management vs. Vulnerability Management: Which Delivers Real Risk Reduction?

Thu, 29 Jan 2026 13:00:01 Z

Vulnerability management has served organizations and the cybersecurity industry for years. It is a capable practice that has helped companies defend their attack surface and prevent threat actors from exploiting vulnerabilities.

But technology and IT infrastructure have evolved. Vulnerability management no longer can meet the challenges that come with this evolution. Now, exposure management is here to provide an even more holistic approach to endpoint security that covers the areas vulnerability management falls short in.

Let’s dive into the distinctions so that you can decide how to protect your organization.

What is vulnerability management?

Vulnerability management is a cybersecurity practice that includes continuous and proactive identification, assessment, prioritization and remediation of vulnerabilities hackers can use to infiltrate your organization.

However, it’s important to note that there are two different types of vulnerability management:

Legacy vulnerability management	Risk-based vulnerability management
Involves attempting to remediate as many vulnerabilities as possible. This often results in substantial effort and unrealistic expectations for success while presenting a false sense of security.	An evolved vulnerability management practice that accounts for risk in vulnerability prioritization. This allows organizations to patch the critical vulnerabilities that pose a real-world threat, protecting your organization from threat actors while also ensuring a strong security posture and effectively managing resources.

A risk-based vulnerability management approach goes beyond legacy vulnerability management, providing your organization with the following benefits:

Continuously monitors vulnerabilities for proactive security.
Identifies actively exploited exposures.
Enables effective remediation efforts.
Reduces risk.
Assists organizations with reaching compliance.

While risk-based vulnerability management covers a lot of bases, it still doesn’t offer the holistic approach to cybersecurity that organizations need to stay safe and secure. That’s where exposure management comes into the picture.

What is exposure management?

Exposure management is an evolving cybersecurity practice that provides comprehensive visibility across your entire attack surface. It allows IT and Security teams to identify exactly where your organization may be exposed while including risk-based prioritization, remediation and more. Exposure management focuses on maintaining an organization’s self-determined risk appetite. Therefore, it encompasses four stages:

Like risk-based vulnerability management, exposure management helps prioritize which vulnerabilities and exposures should be addressed first based on real-world risk, but it goes further by factoring in what is most relevant to your specific business. This cybersecurity approach ensures that the highest-risk exposures are remediated proactively, before they can be exploited by attackers.

Exposure management vs. vulnerability management: What’s the difference?

Exposure management represents the next evolution beyond traditional vulnerability management. While vulnerability management primarily focuses on identifying and addressing weaknesses in servers and endpoints, exposure management expands this scope by delivering complete visibility across the entire attack surface.

In terms of key differences, these include:

Exposure management is designed for newer types of assets: Modern IT environments have grown increasingly complex, now including assets such as Software-as-a-Service (SaaS) applications, IoT devices, cloud infrastructure and more. Exposure management is designed to account for these newer kinds of assets, ensuring IT and security teams can identify risks wherever they exist in the organization. By doing so, exposure management provides a comprehensive understanding of all potential entry points. This empowers organizations to manage and reduce risk more effectively than ever before.
Exposure management understands the reality and champions a risk appetite approach: Again, vulnerability management is centered around patching vulnerabilities. While risk-based vulnerability management provides risk prioritization and remediation orchestration, the practice doesn’t acknowledge the fact that it’s not realistic for an organization to patch every vulnerability. The term risk appetite is an organization’s self-determined measurement of how much risk it is willing to accept. This is a significantly more realistic approach that rallies the organization together to achieve shared KPIs to measure success consistently across teams.
Exposure management goes beyond CVEs and CVSS: Vulnerability management focuses primarily on common vulnerabilities and exposures (CVEs). While CVEs are an important target for most organizations, they are not the only catalysts that threat actors can use to cause damage to your organization. Hackers can still leverage the following exposures (that vulnerability management doesn’t cover) to infiltrate your organization:
Misconfigurations.
Application security issues.
IT system policies.
Privileged access controls.

Tying it back to the holistic approach, exposure management covers all these modern assets. Furthermore, vulnerability management is heavily reliant on the Common Vulnerability Scoring System (CVSS) for remediation prioritization. While CVSS is a solid measurement for severity, it provides an effective risk-adjusted perspective.

Risk is an important factor to keep in mind since it includes whether a vulnerability has been exploited, if it has ties to ransomware/malware or is currently trending. Not factoring risk creates a false sense of urgency with CVSS, causing IT and security teams to waste time and resources on vulnerabilities that are not truly urgent.

How to safeguard your organization

Now that we have covered the differences between exposure management and vulnerability management, it’s time to leverage the advantages that exposure management provides. Learn how Ivanti’s exposure management portfolio can elevate your IT and security teams.

January 2026 Patch Tuesday

Tue, 13 Jan 2026 21:52:53 Z

New year, new updates! Welcome back to the Ivanti Patch Tuesday blog where we provide you critical insights to optimize your exposure management activities.

This month there are a pair of Mozilla CVEs that are suspected of being exploited and a Microsoft CVE that has been exploited.

In addition, Microsoft has a pair of publicly disclosed vulnerabilities that will need to be reviewed to see if your organization may be impacted by the changes Microsoft is making.

There are additional third-party updates from Adobe, and you should expect more from Google and Oracle over the next few days and into next week that should be included in your monthly maintenance.

A side note of good news: Microsoft has broken the Server 2025 update out into a separate KB, so it is only 1.9GB in size, versus this month’s 4GB+ Windows 11 cumulative update.

Microsoft’s exploited vulnerability 

Microsoft has resolved an Information Disclosure vulnerability in Desktop Window Manager (CVE-2026-20805). The vulnerability is rated Important by Microsoft and has a CVSS v3.1 score of 5.5, but it has been confirmed to be exploited in the wild. The exposure could be used to disclose a section address from a remote ALPC port that is user-mode memory. The vulnerability affects all currently supported and extended security update-supported versions of the Windows OS. A risk-based prioritization methodology warrants treating this vulnerability as a higher severity than the vendor rating or CVSS score assigned.

Microsoft’s publicly disclosed vulnerabilities 

Microsoft has resolved a Security Feature Bypass vulnerability in Secure Boot Certification Expiration (CVE-2026-21265). The vulnerability is rated Important by Microsoft and has a CVSS v3.1 score of 6.4, but it has been publicly disclosed. In addition the update, the fix provides a warning regarding certificates that will be expiring in 2026 and details on actions that are required to up renew certificates prior to their expiration. It is recommended to start investigating what actions your organization may need to take to prevent potential serviceability and security as certificates expire.   

Microsoft is addressing an Elevation of Privilege vulnerability in Windows Agere Soft Modem Driver (CVE-2023-31096). The vulnerability CVE ID was assigned by MITRE in 2023. It is rated Important and has a CVSS v3.1 score of 7.8. The CVE has been publicly disclosed. Microsoft’s resolution is to remove the affected drivers from the Windows OS as of the January 2026 cumulative update. Microsoft recommends removing any existing dependencies on this hardware.

Ivanti security advisories 

Ivanti has released no security advisories this month.

Third-party vulnerabilities  

Mozilla has released updates for Firefox and Firefox ESR, resolving a total of 34 CVEs. All three updates have an Impact rating of High. Two CVEs are suspected to be exploited (CVE-2026-0891 and CVE-2026-0892). Both are resolved in Firefox 147 (MFSA2026-01), and CVE-2026-0891 is resolved in Firefox ESR 140.7 (MFSA2026-03).
Expect Google Chrome and Microsoft Edge updates this week in addition to a high-severity vulnerability in Chrome WebView that was resolved in the January 6 Chrome update (CVE-2026-0628).
Adobe has released 11 updates this month affecting DreamWeaver, InDesign, Illustrator, InCopy, Bridge, Substance 3D Modeler, Stager, Painter, Sampler and Designer and Coldfusion. Coldfusion is a priority 1. Everything else is priority 3, but most of the updates include Critical CVEs.
Oracle’s Quarterly CPU is scheduled to release on January 20, so be prepared for updates for Oracle solutions, including Java. Once the Java release is out, expect all of the Java-based frameworks to update over the next few weeks.

January update to-do list

Browser updates are a priority this month. Mozilla resolved two suspected zero-day exploits (CVE-2026-0891 and CVE-2026-0892), and Chrome resolved a high-severity CVE (CVE-2026-0628).
The Windows OS update resolves one exploited and two publicly disclosed vulnerabilities this month, putting the Windows OS update as top priority this month alongside the browser updates.
Review Secure Boot Certificate timelines and usage of Agere Soft Modem drivers to avoid serviceability and security issues.

DLL Hijacking: Risks, Real-World Examples and How to Prevent Attacks

Wed, 17 Dec 2025 14:00:02 Z

There’s been buzz around CVE-2025-56383 (published on Sept. 26, 2025), a hijacking vulnerability in Notepad++ v8.8.3 in which a DLL file can be swapped to execute malicious code.

The CVE has been disputed by multiple parties, but we’re not here to comment on that. However, we are here to comment on DLL hijacking and discuss the very real threat that it poses to an organization. Let’s look into what DLL hijacking is and what measures you can take to keep your DLLs safe.

What DLL hijacking is and how it happens

DLL hijacking (also known as a DLL preloading attack) is a security vulnerability where a legitimate and trusted Dynamic Link Library (DLL) file in a Windows application is replaced with a malicious one.

This method exploits the way applications load DLL files, which contain code and data used by multiple programs. By loading a malicious DLL, a threat actor can execute their own code with the same privileges as the legitimate application, leading to privilege escalation, persistence and defense evasion.

When a program starts, it often needs to load various DLLs to perform specific functions, typically from trusted system directories. However, if an application is not careful about where it looks for these DLLs, it might load a malicious DLL from an insecure or predictable location (i.e., the current working directory or a network share). This can happen if the application does not specify the full path to the DLL or if it searches for the DLL in a directory that can be accessed or modified by an attacker.

While this type of attack is not new, it remains effective due to its simplicity. And although this specific issue pertains to Windows applications, it's important to call out that similar vulnerabilities can affect other operating systems (like Linux and macOS, which use dynamic loading for shared libraries).

DLL hijacking introduces multiple security risks, including:

Data theft: The malicious DLL can intercept and steal sensitive data, such as passwords or personal information.
Compromised systems: The attacker can gain control over the system, potentially leading to further attacks or the installation of additional malware.
Malware: The malicious DLL can act as a conduit for spreading malware, infecting other parts of the system or network.

A DLL can be hijacked in several different ways; here are some of the most common techniques:

Insecure DLL search order: Attackers place malicious DLLs in directories searched before the legitimate DLL's location.
Relative path manipulation: Malicious DLLs are loaded when applications use relative paths.
DLL redirection: Techniques like path manipulation redirect the DLL loading process.
Weak permissions: Attackers replace legitimate DLLs with malicious ones in directories with weak permissions.
Phantom DLL hijacking: Attackers exploit applications loading non-existent DLLs by placing malicious DLLs with the same name in searched directories.

These potential vulnerabilities highlight the importance of secure coding practices and directory permission management when it comes to preventing this form of attack.

How to prevent DLL hijacking and keep your DLLs safe and secure

Although DLL hijacking remains a threat, there are best practices you can follow and implement to reduce your risk for a safer, more secure IT environment.

Secure DLL loading:

Use full paths: Always specify the full path to the DLL when loading it. This ensures that the application loads the DLL from a trusted location (and not from an insecure directory).
Set the safe search path: Use the SetDllDirectory function in Windows to add trusted directories to the search path and exclude insecure ones. This can help prevent the application from loading DLLs from unexpected locations.

File integrity checks:

Digital signatures: Ensure that DLLs are signed with a digital signature and verify the signature before loading the DLL. This can help confirm that the DLL has not been tampered with.
Hash verification: Use cryptographic hash functions to verify the integrity of DLL files. If the hash of the DLL does not match the expected value, the file may have been modified.

User permissions:

Least privilege principle: Run applications with the least privilege necessary. This limits the potential damage of a DLL hijacking, as the malicious code will have fewer permissions to execute harmful actions.
User Account Control (UAC): Enable UAC on Windows systems to prompt users for permission before running applications with elevated privileges. This can help prevent unauthorized changes to system files.

Application control and privilege management:

Known and trusted applications: Application control ensures that only known and trusted applications are launchable, removing the risk of unauthorized applications being introduced.
Privilege control: Effective privilege management is crucial in preventing DLL hijacking. By ensuring that applications have the correct rights and privileges to launch, you limit the ability of unauthorized users to introduce malicious files. This control acts as a key barrier, restricting the access an attacker needs to exploit the DLL search mechanism and thereby enhancing the security of your environment.

Security software:

Antivirus and anti-Malware: Use reputable antivirus and anti-malware software to detect and prevent the loading of malicious DLLs. These tools can scan for known malicious files and behaviors.
Intrusion Detection Systems (IDS): Implement IDS to monitor for unusual activity, such as unexpected changes to DLL files or attempts to load DLLs from insecure locations.

Patch management:

Keep software updated: Regularly update applications and operating systems with the latest security patches. Many DLL hijacking vulnerabilities are fixed via updates, so stay current to help protect against known threats.
Automated patching: Use an automated patch management tool to ensure that all systems are kept up to date without manual intervention. This reduces the window of opportunity for attackers to exploit known vulnerabilities, including those that could be used for DLL hijacking. This proactive approach helps maintain the integrity of your applications and operating systems, making it much harder for attackers to inject malicious DLLs.

By implementing these best practices, you can significantly reduce the risk of DLL hijacking and enhance the overall security of your applications and systems.

Combine the right tools and tactics to prevent DLL hijackings

DLL hijacking has been a persistent form of attack for years, proving that it’s still effective and will therefore continue to be an issue for organizations.

Future-proof your organization using the best practices mentioned above combined with proven solutions like Ivanti Neurons for App Control to help keep your DLLs secure. Capabilities like Trusted Ownership catch and deny a hijacked DLL from being executed by ensuring that ownership of the items matches your approved list of trusted owners.

And, keep your apps up to date to limit exposure to known vulnerabilities. Remove the risk of human error by automating patching with Ivanti Neurons for Patch Management, ensuring that systems are automatically updated and secured.

ITAM: Your Unexpected First Line of Cyber Threat Defense

Tue, 16 Dec 2025 14:00:02 Z

When the conversation turns to cybersecurity, people often think of firewalls, intrusion detection systems or state-of-the-art endpoint protection. Yet, beneath these sophisticated shields is an essential (and often unsung) foundation: robust IT Asset Management (ITAM).

For CIOs guiding mid-sized and enterprise organizations through an increasingly perilous digital landscape, ITAM offers not just operational clarity, but a powerful first line of cyber threat defense.

Below, we’ll explore how comprehensive ITAM delivers critical visibility into your organization’s technology environment, strengthens your defenses against evolving cyber threats, supports regulatory compliance and accelerates security operations. Read on to discover how making ITAM a core part of your strategy can help prevent costly breaches and build true cyber resilience.

Global cyberattacks rose 30% YoY, and ransomware attacks now average 20–25 major incidents per day.

Why ITAM matters: Cybersecurity challenges start with obscured visibility

Cyber threats almost invariably exploit the weaknesses organizations can’t see. Shadow IT, obsolete devices, rogue software and unauthorized access points are invisible vulnerabilities that slip through the cracks of traditional security. A comprehensive asset inventory isn’t just good housekeeping — it's the starting point for effective cyber risk management.

Despite 90% of organizations claiming strong detection capabilities, 57% still suffered major security incidents due to lack of full visibility.

Consider this: in the 2023 Data Breach Investigations Report, Verizon noted that a significant proportion of intrusion incidents stemmed from neglected assets — servers went unpatched because they were forgotten, endpoints were provisioned without visibility into their lifecycle, etc.

Here, ITAM is an invaluable early warning system. By providing a real-time, continually updated map of all hardware, software and cloud assets, it allows IT leaders to spot risks before attackers do.

The benefits of ITAM for cyber resilience

Below we’ll look at how the various benefits of robust ITAM result in a stronger security posture for your organization.

Lifecycle management eliminates weak links

Assets don’t just pose risks at the moment of acquisition. The lifecycle (from onboarding, maintenance, and update to eventual retirement) is fraught with opportunities for mismanagement that can result in potential doorways for cyber adversaries. Obsolete systems without vendor support, end-of-life software still running mission-critical apps, devices decommissioned without wiping — these are common in complex environments.

45% of organizations lack confidence in knowing all applications in use, creating blind spots that attackers exploit.

Robust ITAM ensures that every asset gets tracked, routinely assessed and decommissioned securely, closing off both accidental exposures as well as sophisticated attacks that target legacy infrastructure.

Regulatory compliance proves control and prevents penalties

Increasingly, CIOs face regulatory environments that demand demonstrable control over IT assets. Frameworks such as NIST, ISO 27001 and GDPR all emphasize asset visibility as a prerequisite for effective control of sensitive data and critical infrastructure. A mature ITAM practice maps directly onto these requirements, providing the documentation and provable oversight needed for audits and regulatory inquiries.

Over 80% of breaches are linked to gaps in attack surface management, driven by vulnerable internet-facing assets and poor asset inventory practices.

For example, under GDPR, the ability to swiftly identify and remediate vulnerable assets that process personal data is not just good security practice, it’s a legal necessity.

The ITAM-security partnership: More than just inventory tracking

True ITAM goes beyond keeping lists. Integrated asset management feeds context directly into security operations tools. Vulnerability scanners depend on accurate inventories to detect exposures. Incident response hinges on knowing precisely which systems are implicated. Security policy enforcement relies on a clear understanding of asset roles and relationships.

Anecdotally, one financial institution saw its incident response time halved after integrating ITAM data into its SIEM platform, enabling security teams to immediately pinpoint and isolate affected assets during a breach. The value here is measurable and repeatable.

Resilient cyber defense means robust asset management

IT Asset Management is not merely operational hygiene. It is an essential component of a proactive, resilient cybersecurity strategy. For CIOs, investing in a robust ITAM solution can mean the difference between surface-level security and genuine risk mitigation.

If you’re ready to discover how our ITAM solution can reinforce your organization’s security posture from the ground up, contact our team today and take the first step toward building true cyber resilience.

Is Shadow AI Quietly Reshaping Your Workplace Security Posture?

Mon, 15 Dec 2025 14:00:01 Z

AI tools have seen a meteoric rise in the workplace. What was once the domain of highly specialized tech roles is now commonplace: Ivanti’s 2025 Technology at Work Report found that 42% of office workers say they’re using gen AI tools, like ChatGPT, at work — up 16 points from the previous year.

The catch? These productivity gains happen under the table. Among those who reported using gen AI tools, 46% say that some (or all) of the tools they use are not employer-provided. And, one in three workers keep AI productivity tools a secret from their employers.

Gen AI tools can be a productivity multiplier. But they’re also a risk to data security — particularly when they’re used without employer oversight.

What is shadow AI?

Unsanctioned use of AI is just another flavor of shadow IT (i.e. the use of technology without IT approval).

The risks that shadow AI introduces are similar to other shadow IT risks, but with an additional layer of concern: the sheer amount of proprietary data generative AI requires to be effective. Free generative AI tools (and some paid tools as well) may use an organization’s data or employee searches to train their model, amplifying the risk of data leaks and noncompliance.

The recent revelation that shared ChatGPT conversations were crawlable by search engines (although OpenAI swiftly changed course) should be a wake-up call that, without proper controls, third parties can use your data in ways you object to. Some free tools, ChatGPT included, can be configured to meet security policies, but that’s simply not possible when employees use them covertly.

Free tools like ChatGPT aren’t the only shadow AI risk. An unexpected source is actually existing software. With the rush to add AI features, tools that might previously have been IT-approved may now pose new risks, and if infosec teams don’t know about and evaluate these new features, they effectively circumvent third-party risk management processes.

Why a risk-first approach to AI is crucial

Whether for gen AI or other tools, shadow IT is the result of not having a defined and reasonable way to test tools or get work done. Given that AI isn’t going away, companies need to approach adoption proactively, because banning tools doesn’t mean employees won’t try to use them in an effort to boost their productivity and make their jobs easier.

I spend the bulk of my time assessing risk, including the risks AI tools pose. Often, we have to assess risk as it relates to an opportunity to improve the business — in this case, employee productivity gains and second-order impacts (like employee satisfaction or having time to work on more strategic projects).

In short, we need to ask: Is there a way to introduce the tools employees are asking for and reap the benefits they offer while keeping the risk to an acceptable level?

This is where a risk-first approach enters the picture. A risk-first approach to AI adoption focuses on the data that needs to go into the AI and how the third party handles that data. This approach is similar to vendor risk management, allowing organizations to use established practices and processes, but adjusted for AI-focused questions.

Key question to ask include:

Will our data be used to train the AI model?
How long is our data retained?
What protections exist to reduce the risk of our data being exposed?
Who has the rights to intellectual property generated using the AI?

Minimizing AI sprawl is a critical piece of this work. As more vendors introduce specialized AI tools — and as you bring on more vendors and grant their AI tools access to your data — your risk increases. This is also true of existing tools that suddenly introduce AI without cost or contract changes, making it difficult to keep an accurate inventory of AI tools.

Adopting an AI governance framework at Ivanti

Within Ivanti, we combat shadow AI with a risk-first approach that starts and ends with employee engagement.

Bringing AI use out of the shadows

While we’d never encourage shadow AI, employees that use it have valuable knowledge to share about how to integrate AI into workflows. So instead of banning all AI use, we have to make sure that employees have a clear path to request AI tools to use at work and that there are regular opportunities for open dialogue.

Fostering open dialogue makes employees feel comfortable discussing which tools help them succeed and ultimately means they will use them (or equivalent tools) safely. This provides an opportunity for employees to be active partners in developing appropriate governance — rather than trying to skirt restrictions.

A measured approach to AI implementation and adoption

Once a tool is approved, it is important to ensure proper implementation and that you understand what data you have given it access to. This is particularly important when you consider the data governance and security risk that gen AI tools pose to organizations. When we view AI through the lens of data governance, it can help address many parts of AI risk.

At Ivanti, we take a measured approach: We dedicate a team to run controlled tests of gen AI tools with other teams. We then establish feedback loops, and adoption rolls out gradually to avoid disruption.

Building a feedback loop for AI tools

We have to consistently ask:

How are Ivanti's employees using AI?
Do they like it?
What feedback do they have?
How can we improve the tool?

This ongoing conversation ensures we're using AI responsibly while meeting employees' productivity needs.

It’s not about jumping on the AI bandwagon. It’s about knowing if it’s worth it — for the business and for the people using it. Shadow AI boosts the productivity of one person. But take that productivity and expand it, and you have a meaningful improvement for the company as a whole.

Proactively combating shadow AI

The running theme here is that even though AI, and particularly shadow AI, poses new and concerning risks, it is here to stay. Employees who use AI under the radar aren’t ill intentioned; if anything, they’re trying to benefit the business, even if they’re going about it the wrong way.

A proactive, risk-first approach to AI adoption recognizes this reality. Instead of reactive bans that only encourage circumvention, we have to engage employees to understand the problems they’re using AI to solve so that we can provide them with safe options that meet our security and data privacy requirements.

December 2025 Patch Tuesday

Tue, 09 Dec 2025 22:05:21 Z

Here we are at the final Patch Tuesday for 2025. Microsoft has resolved 56 CVEs (two Critical and 54 Important). Included in this release is one known exploited (CVE-2025-62221) and two publicly disclosed CVEs (CVE-2025-54100 and CVE-2025-64671). This month’s OS update resolves the exploit (CVE-2025-62221) and one of the public disclosures (CVE-2025-54100), making the Windows OS a top priority this month. The other public disclosure is in GitHub Copilot for Jetbrains (CVE-2025-64671), which would require developers to download and update the GitHub Copilot plugin.

Third-party updates this Patch Tuesday include multiple releases from Mozilla for Firefox 146 and Firefox ESR 115.31 and 140.6. Adobe released five updates to resolve 142 CVEs including an update for Adobe Acrobat and Reader. Four of five updates are rated as Priority Three, but the Adobe ColdFusion update is rated Priority One. There are no known exploits, but the ColdFusion update resolves the bulk of the CVEs resolved by Adobe this month.

Microsoft’s exploited vulnerability

Microsoft has resolved an Elevation of Privilege vulnerability in Cloud Files Mini Filter Driver (CVE-2025-62221). The vulnerability is rated Important by Microsoft and has a CVSS v3.1 score of 7.8 but is confirmed to be exploited in the wild. An attacker who successfully exploits this CVE could gain SYSTEM privileges. The CVE affects Windows 10 and later Windows editions. A risk-based prioritization approach would prioritize this CVE as Critical.

Microsoft’s publicly disclosed vulnerabilities

Microsoft has resolved a Remote Code Execution vulnerability in PowerShell (CVE-2025-54100). The vulnerability is rated Important by Microsoft and has a CVSS v3.1 score of 7.8 but has been publicly disclosed. The fix provides a warning and guidance to avoid the potential remote code execution, but the nature of the exposure makes it improbable to fully remediate. The Invoke-WebRequest command can parse the contents of a web page and could potentially run script code in the web page when it is parsed. A warning is presented recommending the use of the -UseBasicParsing switch to avoid script code execution. The CVE affects Server 2008 and later Windows editions.

Microsoft has resolved a Remote Code Execution vulnerability in GitHub Copilot for Jetbrains (CVE-2025-64671). The vulnerability is rated Important by Microsoft and has a CVSS v3.1 score of 8.4 but has been publicly disclosed. An attacker could exploit code using a malicious Cross Prompt Inject in untrusted files or MCP servers, allowing the execution of additional commands by appending them to commands allowed in the user’s terminal auto-approve setting.

Ivanti security advisories

Ivanti has released one security update this month. The update affects Ivanti Endpoint Manager and resolves four vulnerabilities. More details and information about mitigations can be found in the December Security Advisory.

Third-party vulnerabilities 

Mozilla has released updates for Firefox and Firefox ESR resolving a total of 27 CVEs. All three updates have an Impact rating of High.

Adobe released five updates this month affecting ColdFusion, Experience Manager, DNG SDK, Acrobat and Reader and Creative Cloud Desktop. ColdFusion is a Priority One and resolves the majority of the 142 CVEs. The other four updates are rated Priority Three.

December update priorities

The Windows OS update is the priority this month to resolve CVE-2025-62221.

All other updates can be resolved under normal SLA priorities.

Secure the Mobile Edge: Android 16 & iOS 26 STIGs Require MTD

Wed, 03 Dec 2025 20:06:11 Z

Whether it’s Warfighters deployed in the field or remote analysts supporting missions across the globe, mobile devices make these operations possible. But, these endpoints (and your data) need serious protection.

That’s where the Defense Information Systems Agency’s Security Technical Implementation Guides (STIG) come in, setting the baseline for hardened endpoint and application security.

DISA has released new Android 16 and iOS 26 STIGs, and with each major operating system release, these STIGs are updated to ensure mobile security keeps pace with modern threats and capabilities. One of the most significant requirement changes this cycle is that all managed mobile devices must have a mobile threat defense (MTD) solution deployed to remain compliant.

In this post I’ll walk you through the importance of STIGs, why MTD is critical to safeguarding sensitive data and how an MTD solution simplifies compliance across the mobile edge.

STIGs: The gold standard for device security

Think of STIGs as detailed guidelines that tell you exactly how to configure and lock down technology, software, hardware or entire systems to meet Department of War (DoW) security standards.

STIGs ultimately help organizations protect Controlled User Information (CUI) and higher levels of data. Each STIG contains specific requirements (or “controls”) that make up the security baseline.

They (and associated security requirements guides) are linked to security controls defined by National Institute of Standards and Technology (NIST) Special Publication 800-53, breaking them down into actionable, measurable items.

For example, a mobile device STIG might stipulate that:

Device passcodes must be complex, with at least X characters.
The device must encrypt all data.
USB debugging must be disabled.
A mobile threat defense app must be installed.

U.S. military and government agencies rely on STIGs to harden systems that support mission-critical operations. While they’re mandatory for DoW and federal agencies, many defense contractors, healthcare and finance organizations adopt STIGs because they represent proven security best practices.

STIGs provide a baseline to help these organizations maintain compliance with a variety of requirements and policy mandates, such as Cybersecurity Maturity Model Certification (CMMC), NIST, CIS, HIPAA, etc.

Your new mandate: iOS 26 & Android 16 STIGs now require MTD

On the Apple side, the iOS 26/iPadOS 26 STIG added an explicit requirement: to remain compliant, an MTD app must be installed and managed on all DoW iPhones and iPads.

The latest Android 16 STIGs (i.e., Google Android 16 STIG and Samsung Android 16 STIG) introduce a clear mandate as well: a mobile threat defense (MTD) application must be deployed on every managed device. Failure to do so is flagged as a finding during compliance review.

These controls underscore a pivotal shift: Mobile endpoint risk management is no longer just about configuration and lockdown settings. It now includes actively enforcing real-time mobile threat defense to prevent device, network, application and phishing attack vectors on modern devices.

Here's the exact language on MTD from the Android 16 STIG:

"In the mobile device management (MDM) console, verify an MTD app is listed as a managed app being deployed to site-managed devices. If an MTD app is not installed on the device, this is a finding."

Translation: No MTD means you're out of compliance. It's that simple. However, deploying an MTD solution and ensuring it’s actively protecting against mobile threat vectors is more complex.

Integrating an MDM/MTD approach

Having worked with countless federal and enterprise organizations, I’ve seen firsthand what truly works in the field. Installing and managing an MTD agent is not enough to ensure active protection on mobile endpoints.

Standalone MTD agents often require manual activation after installation and application programming interface (API) integrations with MDM solutions to take action. The most effective approach requires tight integration between your MTD and MDM platforms, and an integrated MDM/MTD agent to ensure seamless activation and protection from mobile threats.

A unified single-agent architecture enables continuous mobile threat protection while automatically enforcing MDM compliance controls, eliminating the complexity and gaps that come with managing separate solutions.

That's where Ivanti Neurons for Mobile Threat Defense comes into play. With Ivanti Neurons for Mobile Threat Defense integrated in both the SaaS-based Ivanti Neurons for MDM and on-prem-based Ivanti Endpoint Manager for Mobile (EPMM), you get a single-agent architecture that's seamless to users but gives administrators complete control and security visibility.

This is what it looks like in practice:

Automatic and scalable STIG baseline enforcement for Android and iOS.
Users experience a seamless workflow with no additional apps or agents to manage.
Risk visibility and policy management live in one unified console.
On-device threat protection works even in disconnected, deployed scenarios to protect against device, network, application and phishing attacks.
An integrated MDM that manages any modern operating system including iOS, Android, Windows, macOS or ChromeOS.

MDM & MTD for holistic mobile security

Deploying an MTD app is no longer optional. With the Android 16 and iOS 26 STIG both calling for MTD on managed devices via explicit controls, you can’t rely solely on MDM configuration baselines. You need active MTD that gives you holistic security.

With mobile threat vectors like operating system vulnerabilities, malicious mobile apps, phishing via SMS/MMS and network man-in-the-middle attacks, rising rapidly, you need protection that lives on the device itself — not just in the cloud.

Compliance, mission assurance and mobile edge security are top priorities for every modern organization. Ivanti Mobile Threat Defense delivers on all three. Providing STIG-aligned protection across Android and iOS devices, integrating seamlessly into your broader device management platform and defending against device, network, application and phishing attacks to keep your organization resilient and compliant.

Schedule a demo today to see how Ivanti Mobile Threat Defense can keep your agency’s data safe and your mobile fleet audit-ready. For full STIG references and downloads, consult the Defense Information System Agency’s (DISA) STIG library.

Understanding External Attack Surface Management: How It Works and Why It’s More Critical Than Ever

Tue, 02 Dec 2025 15:06:33 Z

Attack surfaces can expand without your organization even realizing it. And, lacking visibility into your external-facing assets and the vulnerabilities they may contain can lead to significant security risks.

External attack surface management (EASM) is a cybersecurity approach designed to safeguard your external assets and strengthen your organization's overall security posture. It does this by providing full visibility into these assets (and associated vulnerabilities) that could be exploited by threat actors.

In this article, we’ll walk you through how EASM works, the risks involved with overlooking your external attack surfaces, the benefits as well as where EASM sits in the broader practice of exposure management.

How external attack surface management works

EASM is the practice of identifying and managing your external-facing assets (e.g., websites, APIs, etc.) to prevent security breaches. Additionally, the process includes identifying attack surface gaps that can expose your organization to cybersecurity risks.

EASM helps fight unwanted expansion of your attack surface through visibility, enabling your organization to stay up to date on your potential vulnerabilities. Leveraging EASM provides the following benefits:

Additional source of discovery and asset visibility.
Curbs cloud sprawl and shadow IT.
Reduces AI-powered phishing tactics.
Analyzes and prioritizes exposures.
Detects data leakage.
Reduces phishing and social engineering attacks.
Adheres to regulatory compliance requirements.
Extend your vendor risk management by providing external risk perspective of third-party vendors.

EASM involves multiple key stages, including Discovery, Assessment, Prioritization, Reporting and Remediation.

Discovery

As mentioned above, EASM involves monitoring your external attack surface to identify those assets to both catalog them and uncover vulnerabilities that could lead to a hacker infiltrating your organization.

It doesn’t involve an invasive scan. Rather, it involves a passive crawl of your external attack surface, and all you need is a URL to start the process. EASM solutions, for example, use public data in combination with security intelligence. The assets that make up your external attack surface include:

Web servers.
DNS servers.
IoT devices.
Network edge devices.
Application servers.
Certificates.
Cloud-based tools.
Shadow IT.

Learn more: How to Identify Your Organization’s Attack Surface

Assessment

Thorough and continuous assessment is essential to understand your organization's risk landscape and effectively prioritize remediation efforts. At this stage, your organization evaluates whether the assets identified during the discovery process are in use and if they are harboring vulnerabilities. EASM solutions do this by identifying publicly disclosed security weaknesses, outdated software versions and more.

By examining these assets for vulnerabilities and other potential security risks, you gain crucial insights into your security posture.

Prioritization

Once vulnerabilities are identified, the next step is to determine which ones to address first based on their risk to your organization. Since it’s often impractical to remediate every vulnerability, risk scoring methods help you assess the urgency and impact of each exposure. This allows your security teams to focus on the most critical issues, streamlining the remediation process and ensuring that resources are allocated effectively.

Reporting and remediation

The next stage in EASM is to report on these risks and begin remediation. EASM solutions enable you to generate comprehensive reports that offer an overview of your external attack surface, along with detailed breakdowns of critical vulnerabilities. These reports are invaluable for communicating the nature and urgency of potential threats, helping stakeholders understand the importance of prompt remediation and informing decisions.

The risks involved with not monitoring your external attack surface

If your organization does not have full knowledge of the external attack surface, you risk having unknown or unmonitored assets or misconfigurations that open you up to attack, resulting in reputational damage, financial loses and more.

The lack of visibility into shadow IT, misconfigured or forgotten services allows for easy entry points for attackers. According to Computer Weekly, identity and access management company Okta was exposed to multiple security breaches due to shadow IT.

Furthermore, these assets are visible to anyone on the internet. It doesn’t require any special skills for someone to obtain this information about your external attack surface, meaning it is straightforward for a threat actor to gain access to your organization if you don’t enact proper measurements.

Now that you have an overview of external attack surface management, it’s important to understand that it’s just one part of your larger attack surface, which is where exposure management comes into play.

How EASM plays into exposure management

Exposure management focuses on asset visibility, exposure aggregation, risk-based prioritization and remediation of exposures. It’s a comprehensive cybersecurity practice that helps organizations define their risk appetite and keep levels within acceptable bounds.

EASM is just one part of exposure management (visibility, as shown in the graphic above). In cybersecurity, you can’t protect what you can’t see. So, let Ivanti help you get full visibility into your external attack surface with Ivanti Neurons for EASM.

November 2025 Patch Tuesday

Tue, 11 Nov 2025 20:26:09 Z

November Patch Tuesday is the first Patch Tuesday after the EoL of Windows 10. In the shadow of Windows 10, there are a number of other product EoLs of note. Exchange Server, for one, is getting some additional attention. Microsoft announced a 6-month ESU option for Exchange 2016/2019 servers for customers who need the extension. Their guidance, however, is not to rely on this program and to make every attempt to move off of Exchange and move to Exchange SE in time. Cybersecurity agencies across the globe have also collaborated to provide a Security Best Practices guide for Microsoft Exchange Server.

Microsoft resolved 63 unique vulnerabilities this month, including one known exploited CVE (CVE-2025-62215). The exploited CVE is an Elevation of Privilege vulnerability in the Windows Kernel that can allow an attacker to gain SYSTEM-level privileges on the target system. Affected products this month include Windows OS, Office, SharePoint, SQL Server, Visual Studio, GitHub Copilot and Azure Monitor Agent.

For third-party updates, Oracle released their quarterly Critical Patch Update on October 21, 2025. This included many updates including Java. With the release of Java comes a stream of Java framework updates, including RedHat OpenJDK, Amazon Corretto, Azul Zulu, Eclipse Adoptium, Adopt OpenJDK and others.

Patch Tuesday third-party updates include eight from Adobe and three from Mozilla, and Google Chrome released a stability and performance update this month (no CVEs reported).

Microsoft’s exploited vulnerability

Microsoft has resolved an Elevation of Privilege vulnerability (CVE-2025-62215), which Microsoft has confirmed is exploited in the wild. The CVE is rated Important and has a CVSS 3.1 score of 7.0. The vulnerability requires an attacker to win a race condition, but if exploited it would allow the attacker to gain SYSTEM privileges on the affected system. The vulnerability affects all currently supported Windows OS editions and Windows 10 ESU, which means the risk of running Windows 10 past the EoL without ESU is not hypothetical. Ensure you are subscribing to Windows 10 ESU and providing additional mitigations where possible.

Ivanti security advisories

Ivanti has released one Security Advisory for November Patch Tuesday, resolving three CVEs. The security advisory for Ivanti Endpoint Manager provides details on vulnerable versions. Also, the advisory reminds Ivanti Endpoint Manager customers that version 2022 reached End of Life at the end of October 2025. All Ivanti EPM customers are urged to upgrade to 2024 SU4 to remediate the three vulnerabilities.

For more details, you can view the updates and information provided in the November Security Update on the Ivanti blog.

Third-party vulnerabilities

Adobe released eight updates resolving 28 CVEs. All eight updates are rated priority three.
Mozilla released three updates resolving a total of 29 CVEs.
Google Chrome just released a stability and performance update, but it has resolved 27 CVEs since October Patch Tuesday.

November update priorities

The Windows OS is the highest priority this month, with one zero-day exploit.
Continue to monitor your environment for EoL software. Beyond Windows 10 EoL, there are editions of Office that are now EoL along with Exchange. The first month after the Windows 10 EoL has a zero-day that affects the Windows 10 OS. The risks of continuing to run EoL software without extended support are very real, and threat actors will be looking to take advantage.

Vulnerability Prioritization: The Complete Guide

Thu, 30 Oct 2025 15:28:29 Z

With thousands of vulnerabilities discovered every year, not all pose the same risk. Some can cripple critical systems, while others have little real-world impact.

The key is knowing which threats to act on first. Vulnerability prioritization helps security teams cut through the noise, focus on what truly matters and build resilience against critical attacks.

What is vulnerability prioritization?

Vulnerability prioritization is the process of ranking vulnerabilities based on risk factors, such as exploitability, asset importance, threat intelligence and business impact.

Rather than reacting to every alert, proper prioritization allows organizations to focus on the vulnerabilities that pose the greatest danger to the business. Without prioritization, security teams risk wasting time patching low-risk flaws while missing critical exposures that attackers could exploit. If done well, prioritization enables smarter resource allocation, faster response to urgent threats and better alignment with compliance and business goals.

When talking about vulnerability management, it’s helpful to separate detection from prioritization: detection is the act of finding and listing vulnerabilities (often by using scanners or automated tools), while prioritization is the process of deciding which of those vulnerabilities to fix first, based on factors such as risk, likelihood of exploitations, business context and asset value.

In other words, detection is about making the list, and prioritization is about sorting through it by urgency and impact.

What is risk-based vulnerability prioritization?

Traditional methods of risk prioritization often rely solely on CVSS scores. While helpful, severity ratings alone ignore context, treating all environments with the same and overlooking business-critical risks.

Risk-based prioritization shifts the focus to what truly matters by incorporating:

Asset criticality
Type of exploit and active threats
Business impact
Threat intelligence

Combining these elements, risk-based prioritization ensures your security team focuses on vulnerabilities that are both exploit-ready and business-critical, instead of scattering efforts across every scan finding (many of which might be low-risk).

Without this approach, you risk patching low-impact test-server issues while overlooking high-impact, high-exploit vulnerabilities in your most critical assets. This method creates a triage process rooted in actual risk rather than just technical severity.

Advantages of risk-driven approaches

Adopting a risk-based approach shift the focus from only recognizing the severity of a vulnerability to addressing the factors the truly put your organization at risk. Here’s why that matters:

Reduced noise — Eliminate alert fatigue by filtering out low-risk vulnerabilities that don’t require immediate action.
Faster remediation of critical issues — Focus on your limited resources on the vulnerabilities most likely to be exploited.
Better alignment with business goals — Prioritize what matters to your organization, not just what is perceived as urgent.
Improved collaboration — Security, IT and DevOps teams can work from a shared understanding of what’s most important.

Risk-based vs. traditional prioritization models

Below is a quick reference table to help you understand how risk-based vulnerability prioritization contrasts with traditional approaches.

Traditional approach	Risk-based approach
Based mostly on CVSS scores.	Incorporates exploitability, asset value and threats.
Treats all high CVSS scores equally.	Recognizes that not all "high" CVEs are high risk.
Generic, one-size-fits-all.	Tailored to your specific environment.
Often leads to patching low-impact vulnerabilities.	Focuses on what truly affects your business.

How to prioritize vulnerabilities

Identifying vulnerabilities is only the beginning. With thousands of possible issues across networks and applications, knowing what to fix first is essential. Modern prioritization considers:

1. Asset criticality: Not all assets are equal. A flaw in a public-facing portal handling sensitive data is far riskier than one on a test server. Classifying assets by business value helps direct attention to where it counts.

2. Exploitability and threat intel: A vulnerability isn’t always a threat — unless attackers are actively exploiting it. Prioritize issues on the CISA KEV list, including ransomware kits, or with public exploits first.

3. Severity (CVSS): CVSS provides a baseline but should not be the only factor. High scores without exploitation may be less urgent, while medium scores with active threats may require faster action.

The Common Vulnerability Scoring System (CVSS) provides a standardized way to assess the severity of a vulnerability (typically on a scale of 0.0 to 10.0):

Why it matters:

CVSS helps establish a baseline, especially in large-scale scanning. However, severity scores alone don’t take into account business or environmental context, so they shouldn’t be the only factor.

Best practices for effective vulnerability prioritization

Prioritization shouldn’t be an afterthought. You should build it into every stage of your vulnerability management process.

From the moment vulnerabilities are discovered, you should evaluate them based on the risk factors mentioned above to ensure remediation aligns with your organization’s threat landscape and operational priorities. Integrating prioritization early also helps reduce bottlenecks and streamline remediation workflows.

Integrate into the VM lifecycle: Evaluate vulnerabilities by risk from the moment they’re discovered.
Leverage automation: Tools like Ivanti Neurons for RBVM combine CVSS, threat intel and asset context to automatically assign risk scores.
Continuously monitor: Threats evolve; a low-risk flaw today could become critical tomorrow. Regularly refresh threat feeds and reassess priorities.
Foster collaboration: Security brings risk context; IT provides operational insight. Working together ensures prioritization is both effective and realistic.

Manual prioritization is unsustainable at scale. To handle large volumes of vulnerabilities, organizations should leverage tools like Ivanti Neurons for RBVM and Ivanti’s Exposure Management solutions.

These platforms combine threat intelligence, CVSS scores, asset context, and business impact to automatically assign risk scores and suggest prioritization. Automation not only saves time but also improves accuracy and consistency, helping security teams respond to critical threats faster.

Vulnerability prioritization matrix: Make more strategic decisions

With security teams overwhelmed by thousands of vulnerabilities, effective prioritization isn't a luxury — it's a necessity. One of the most straightforward visual tools for helping teams decide what to fix first is the vulnerability prioritization matrix.

What is a vulnerability prioritization matrix?

A vulnerability prioritization matrix is a visual decision-making framework that helps security teams rank vulnerabilities based on multiple risk factors (typically likelihood and impact).

It plots vulnerabilities on a grid or heatmap, helping teams see at a glance:

Which vulnerabilities pose the highest risk.
Which vulnerabilities can be deferred or monitored.
How to allocate remediation resources.

Think of it as a risk lens that turns raw vulnerability data into actionable insights.

When to use a prioritization matrix

A vulnerability matrix is especially helpful when:

You have limited resources and need to justify what to patch first.
You're dealing with competing priorities across teams.
You need a clear, communicable visual for non-technical stakeholders.
You're building a case for risk acceptance vs. mitigation.

It’s a great tool for quarterly risk reviews, incident response planning, or as part of a risk-based vulnerability management (RBVM) program.

Prioritize vulnerabilities for resilience against critical threats

Vulnerability prioritization transforms endless scanning results into a clear, actionable roadmap. By going beyond severity scores to include exploitability, business impact and environmental context, organizations can focus on the vulnerabilities that truly matter. With risk-based approaches, visual tools like matrices, automation and cross-team collaboration, security teams move from reactive patching to proactive, risk-informed prevention.

In today’s threat landscape, simply detecting vulnerabilities versus prioritizing them effectively can mean the difference between resilience and compromise.

Why SELinux Matters in Enterprise Security

Thu, 23 Oct 2025 14:03:35 Z

When evaluating cybersecurity products, it's easy to focus on surface-level features like dashboards, alerts and integrations. But real strength often lies more deeply, in the architecture itself. One embedded capability that demonstrates rigorous security design principles is Security-Enhanced Linux (SELinux).

Originally developed by the U.S. National Security Agency (NSA) and released to the open-source community, SELinux is a mandatory access control (MAC) framework built into the Linux kernel. It enforces strict, policy-driven rules that govern how applications, services and users interact with system resources, making it a powerful defense against privilege escalation, lateral movement and zero-day exploits.

If the cybersecurity product you're evaluating includes SELinux, especially in enforcing mode, that’s a strong indicator of architectural maturity and proactive threat containment.

What makes SELinux different and better?

SELinux labels every process and file with a security context and uses pre-defined policies to control how they interact. Unlike traditional access controls that rely on user permissions, SELinux enforces security policies to all users and processes, even those with root (administrator) privileges.

This is a big deal because it prevents attackers from exploiting root access to move laterally, exfiltrate data, or disable security controls. SELinux essentially removes the "superpower" status of root, enforcing security boundaries that are defined by policy, not privilege.

This means that even if an attacker gains privileged (aka root) access, SELinux can prevent them from executing unauthorized actions that deviate from the pre-set policy. This level of security goes beyond detection to encompass prevention at the operating system level.

How SELinux works

SELinux runs in multiple modes:

Disabled: Not active, no security enforcement.
Permissive: Logs violations but doesn’t block them; useful for testing.
Enforcing: Actively blocks unauthorized actions based on policy.
Strict enforcement: Refers to enforcing mode combined with a strict policy that is enforced by default.

Products that run SELinux in strict enforcing mode offer real-time protection of the system’s processes and resources. The attack surface is minimized, making it significantly harder for attackers to move around the system. Every user, service and daemon is subject to mandatory least-privilege access control. Strict enforcement is typically used in high-security environments (e.g., government, finance, defense) where no process is trusted by default, and every interaction must be explicitly allowed by policy.

While you won’t be configuring SELinux yourself, it helps to understand how vendors like Ivanti use it to harden their products:

1. Starting in permissive mode: We begin by observing system behavior under SELinux policies without blocking anything.

2. Extensive testing: We log violations, identify legitimate operations and refine policies to avoid false positives.

3. Custom policy development: Policies are tailored to the product’s architecture and use cases.

4. Lab validation in enforcing mode: Before release, we test SELinux in enforcing and strict enforcement modes under simulated real-world conditions.

This process ensures that SELinux enhances security without disrupting functionality, and that users get optimal protection without performance trade-offs. Further, the process outlined above is on a per-release basis — meaning, as the software evolves to newer versions, the SELinux policy must be tested, tuned and repeated with every new version of the software product.

This process is time consuming and demands substantial development resources to execute properly. Only the most dedicated and lean-forward security vendors configure SELinux with strict enforcement.

Real-world example: Oracle Linux deployment

Oracle Linux supports SELinux in enforcing mode and is widely used to secure Oracle database environments and workloads on Oracle Cloud Infrastructure. SELinux helps isolate processes, enforce least privilege and protect sensitive data from unauthorized access — even in complex enterprise deployments.

For buyers, this means that products built on Oracle Linux with SELinux enabled, including Ivanti Connect Secure, are already hardened against many classes of attack. (You can find more details in Oracle’s official guide.)

Security technology that delivers business value

When SELinux is embedded in a cybersecurity solution, the technology delivers strategic benefits that align with enterprise priorities.

Audit and compliance readiness: SELinux logs every access attempt, successful or denied, creating a rich audit trail. SELinux enforcement and audit trail helps meet regulatory requirements like CIS Level-1/2 Hardening, STIG, NIST-800 and other regulations that require system hardening.
Granular access control: Fine-grained rules are enforced at the process level, limiting access even for root users. This reduces the risk of privilege escalation and insider threats, which is especially important in environments with sensitive data or complex user roles.
Reduced attack surface: SELinux isolates processes and enforces least-privilege access, which prevents lateral movement within the system. This containment strategy is critical for limiting the blast radius of any breach. SELinux blocks unauthorized actions at the OS level, making it harder for attackers to exploit vulnerabilities, including zero-days.
Enterprise-grade assurance: Vendors like Ivanti that use SELinux in their products are demonstrating a significant commitment to security best practices. This approach supports risk management, enhances trust and distinctly differentiates the solution in a competitive market.
Operational stability: When policies are properly tuned, SELinux operates silently in the background, enforcing security without impacting performance which is ideal for mission-critical environments where uptime matters.

Final thoughts on SELinux value

Buyers evaluating cybersecurity products should look beyond surface-level features and ask what’s protecting the system at its core. SELinux is one of those under-the-hood technologies that quietly enforces real protection, blocking unauthorized actions (even from privileged users) and containing threats before they spread.

Its presence in a product signals a hardened architecture, proactive threat containment and a vendor that takes system integrity seriously. You won’t configure it yourself, but you’ll benefit from it every time an exploit fails to gain traction.

Ivanti's commitment to security

Ivanti was one of the first to sign onto CISA’s “Secure by Design” pledge in 2024. As part of this effort, Ivanti has invested heavily in hardening the Connect Secure product, modernizing its operating system and embedding security into every layer of development.

At the core of Ivanti’s development philosophy is our Secure Software Development Lifecycle (SSDLC), enabling the seven key elements of Secure Software Design: Security as Code (SaC), Secure by Default, Least Privilege, Separation of Duties (SoD), Minimize Attack Surface Area (ASA), Complete Mediation and Failing Securely. Additionally, Ivanti also follows their own strict Secure Application Development Standard, which mandates compliance with the OWASP Application Security Verification Standards (ASVS). Together these rigorous frameworks ensure that every product feature is designed and implemented with security as a primary consideration, providing customers with solutions that meet the highest industry benchmarks.

October 2025 Patch Tuesday

Tue, 14 Oct 2025 21:43:03 Z

October Patch Tuesday is going to be a busy one from all angles. Microsoft exceeded the January CVE count (159 CVEs) by a healthy margin, with 172 CVEs resolved this month. There are three exploited and two publicly disclosed vulnerabilities this month, but fortunately all of them are in the cumulative OS update, making resolution quick and clean. They are also end of life-ing a lot of products, including Windows 10! Additionally, Office 2016 and 2019 and Exchange Server 2016 and 2019 have also reached end of life.

Adobe released 12 updates resolving 36 CVEs. Mozilla released five updates resolving 45 CVEs and are cautioning users that three of these CVEs are showing signs they may have been exploited in the wild (unconfirmed). And of course, Google Chrome is expected to release their weekly update in the next 24 hours.

There is a lot to unpack, so let’s get started.

Microsoft’s exploited vulnerabilities

Microsoft has resolved a Secure Boot bypass in IGEL OS before 11 vulnerability (CVE-2025-47827), which Microsoft has confirmed is exploited in the wild. The CVE is rated Important and has a CVSS 3.1 score of 4.6. Secure Boot can be bypassed because the igel-flash-driver module improperly verifies a cryptographic signature, allowing a crafted root file system to be mounted from an unverified image.

Microsoft has resolved an Elevation of Privilege vulnerability in Remote Access Connection Manager (CVE-2025-59230), which Microsoft has confirmed is exploited in the wild. The CVE is rated Important and has a CVSS 3.1 score of 7.8. Improper access control in Windows Remote Access Connection Manager allows an authorized attacker to elevate privileges locally. A risk-based prioritization methodology would warrant treating this as Critical.

Microsoft has resolved an Elevation of Privilege vulnerability in Agere Modem Driver (CVE-2025-24990), which Microsoft has confirmed is exploited in the wild. The CVE is rated Important and has a CVSS 3.1 score of 7.8. The driver shipped natively with the Windows OS. Microsoft has removed the driver with the October cumulative update and recommends removing any existing dependencies on this fax modem hardware. Exploit is possible even if the drive is not being used. A risk-based prioritization methodology would warrant treating this as Critical.

Microsoft’s publicly disclosed vulnerabilities

Microsoft has resolved an Elevation of Privilege vulnerability in Agere Modem Driver (CVE-2024-24052), which Microsoft has confirmed is publicly disclosed. The CVE is rated Important and has a CVSS 3.1 score of 7.8. The exploit code maturity is listed as proof-of-concept, which increases the risk of exploitation. A risk-based prioritization methodology would warrant treating this as Critical.

Microsoft has resolved an out-of-bounds read vulnerability in TCG TPM2.0 reference implementation (CVE-2024-2884), which Microsoft has confirmed is publicly disclosed. The CVE is rated Important and has a CVSS 3.1 score of 5.3. The exploit code maturity is listed as unproven, indicating there is currently no publicly available code.

Ivanti security advisories

Ivanti has released two updates and one Security Advisory for October Patch Tuesday, resolving a total of seven CVEs. The affected products include Ivanti Neurons for MDM and Ivanti Endpoint Manager Mobile. The Ivanti Neurons for MDM vulnerabilities were resolved for all customers on October 10, 2025. An additional Security Advisory was released for Ivanti Endpoint Manager, which provides mitigation options for vulnerabilities disclosed October 7, 2025.

For more details, you can view the updates and information provided in the October Security Update on the Ivanti blog.

Third-party vulnerabilities

Adobe released 12 updates addressing 36 CVEs. Adobe has rated the Commerce update as a priority two and the rest of the updates as priority three.
Mozilla released five updates resolving 45 CVEs. Three of the CVEs included variations of the statement, “Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code,” indicating a possibility of exploitation in the wild. All five updates include at least one of the suspected exploit CVEs, we recommend treating all five as containing a known exploited CVE.
Google Chrome is expected to release in the next 24 hours, so plan a Chrome update and a possible Edge update shortly after.

October update priorities

The Windows OS cumulative update is the top priority this month, as it resolves three exploited and two publicly disclosed CVEs.
All Mozilla updates should be deployed during your current maintenance, but any deferral or delay would come with risks as there are three CVEs that are speculated to be exploitable in the wild already.

Boards Talk Cybersecurity — but NIS2 Directive Says They Must Own It

Mon, 29 Sep 2025 20:05:33 Z

Cybersecurity finally has a seat in the boardroom. Ivanti’s 2025 State of Cybersecurity research shows that:

89% of organizations now discuss cybersecurity at the board level.
81% of organizations have at least one director with cyber expertise.
88% of organizations include the CISO in strategic meetings.

On paper, that’s progress. But, many organizations struggle to convert board-level attention into sustained, measurable risk reduction.

Ivanti’s data exposes the crux of the problem: only 40% of security teams say risk exposure is communicated to executives “very effectively” — a governance gap with legal and financial consequences under the EU’s NIS2 Directive.

Let’s take a deeper look at the data from Ivanti’s 2025 State of Cybersecurity Report to see what it tells us — and how to turn those insights into NIS2-ready governance.

Why NIS2 changes everything about cybersecurity risk management

NIS2 broadens the EU’s cybersecurity regime to 18 sectors, tightens supervision and — most consequentially — assigns direct accountability to the management body. Boards and senior leaders must approve, oversee and ensure that measures are proper to the risks and effective in practice.

Failure carries consequences: audits, binding instructions and administrative fines up to €10 million or 2% of global turnover. In serious cases, leaders face temporary bans or personal liability.

Rather than a one-size-fits-all checklist, NIS2 expects organizations to prove they manage risk across the lifecycle (analysis, incident handling and continuity, secure development and supply chain assurance, vulnerability management, training and safeguarded communications) in a manner that’s aligned with the state of the art and proportionate to business impact (per Article 21).

Why boards struggle — and what’s at stake

When you translate risk into dashboards of CVE counts, patch rates and tool inventories that obscure business impact, your board of directors misses the CISO’s key points.

Ivanti’s findings crystallize the disconnect: the conversation is happening, yet few feel exposure is conveyed in a way executives can act upon. The result is misguided prioritization, diffuse budgets and latent exposures that go unaddressed — precisely the scenario NIS2 seeks to prevent.

When things go wrong, costs mount fast. Operational disruption from ransomware, reputational damage, escalating legal exposure and recovery bills often dwarf any administrative fine. With NIS2, ignorance is not a defense; and effective governance requires comprehension, communication and follow-through.

Top cybersecurity risks that demand board attention

Ivanti’s research highlights where organizations are least prepared and most exposed:

Ransomware and AI
End-of-life technology
Supply chain security
Blind spots (e.g., shadow IT)

Each risk below maps to NIS2’s governance expectations. Read on to learn about the threat they pose and how to do better in practice.

1. Ransomware + AI: The perfect storm

The reality from Ivanti’s research: Ransomware still dominates the 2025 threat landscape — and the stakes are rising. Over a third of security professionals (38%) believe AI will make attacks more dangerous, yet only 29% feel very prepared to respond.

This gap reflects a familiar pattern: adversaries accelerate with automation while defenders wrestle with fragmented telemetry, manual processes and untested response playbooks.

How supervisors judge readiness: Under NIS2, resilience cannot be theoretical. Regulators expect response and crisis plans that have been exercised, continuity and recovery targets that are met in practice and preventive controls aligned to business impact (especially identity and patching for critical systems).

When a significant incident hits, the standard is clear: prompt early warnings, coherent follow-ups within mandated windows and visible command of the situation from containment through recovery.

Raise your security posture: Treat ransomware as a recurring business risk, not a rare IT event. Rehearse the first 24–72 hours with top leadership, legal and communications so you can make fast, defensible decisions and produce the evidence a supervisor will ask for.

Don’t just cycle backups — prove restorability of priority services under realistic constraints; tie RTO/RPO directly to revenue and safety. For prevention, orient around exposure: harden and patch critical assets and reduce blast radius with strong authentication, segmentation and least privilege.

When the board asks for assurance, answer in outcomes: “order-to-cash restored in X hours, confirmed quarterly; stakeholder comms aligned to NIS2’s staged reporting.”

2. End-of-life technology: A compliance time bomb

The reality from Ivanti’s research: Over half (51%) of organizations continue to run end-of-life (EOL) software, and one in three organizations say their security is seriously compromised by legacy tech. These legacy blind spots create systemic risk and undermine any claim to state-of-the-art security.

How supervisors judge readiness: NIS2 does not dictate versions, but it does hold you to the principles of appropriateness and state of the art. That means:

You know where EOL sits.
You have a plan to retire it.
You mitigate risk while it stays and you decommission securely — including sanitizing data — when it exits service.

Under Article 21, keeping unsupported tech in production without timeboxed, documented mitigations is hard to defend as proportionate risk management.

Raise your security posture: Move EOL from backlog item to board-owned exposure.

Maintain a live inventory that flags support status a year ahead.
Align the retirement path with business owners.
Where delay is unavoidable, approve temporary isolation on the network, restricted access and enhanced monitoring — with clear end dates.
Close the loop with verifiable data sanitization and auditable records at disposal.

Most importantly, price the risk: “This legacy platform drives X% of revenue; extending nine months adds €Y expected loss unless we isolate and monitor it as follows...”

3. Supply chain security: Your weakest link

The reality from Ivanti’s research: Nearly half (48%) of organizations have not identified the third-party systems or components that are most vulnerable in their software supply chains. Many still rely on static questionnaires — time consuming, self-reported and poor at surfacing live risk — particularly for software components and managed providers.

How supervisors judge readiness: Accountability doesn’t stop at the perimeter. Supervisors will look for a defensible method to judge supplier security (including secure development and vulnerability disclosure), contractual duties that mirror that method, ongoing visibility into partner risk (not just annual forms) and the ability to detect and respond when an originating exposure sits with a vendor.

Article 21 makes this explicit: Supply chain security must be risk-based and proportionate. Software security in the supply chain should be a shared responsibility.

Raise your security posture: Start by matching the depth of your security requirements to the risk the supplier introduces to your environment.

A cloud provider hosting critical workloads requires far more stringent controls than a low-impact SaaS tool. For high-risk vendors, demand tangible evidence — SBOM availability, patch and disclosure cadence, participation in coordinated vulnerability disclosure — and make these obligations enforceable in contracts.

Replace one-off surveys with near-real-time indicators, such as exploit telemetry, remediation timeliness and changes in the supplier’s attack surface. Finally, rehearse a supplier-originating incident together: confirm contacts, evidence sharing and public communications that satisfy NIS2’s staged notifications.

4. Blind spots: The hidden risk you can’t manage

The reality from Ivanti’s research: Shadow IT, legacy systems, unmanaged devices and third-party dependencies are persistent blind spots for many organizations.

These gaps slow response, obscure risk and leave organizations exposed to breaches and compliance failures.

How supervisors judge readiness: Article 21 expects organizations to manage risk across the lifecycle — including asset inventory, vulnerability management and supply chain assurance.

Blind spots undermine that mandate. Supervisors will ask: can you prove you know what is in your environment, what’s vulnerable and what is being done about it?

Raise your security posture: Treat visibility as a governance priority, not a technical detail.

Conduct regular attack surface assessments.
Integrate IT and security data.
Use automation to correlate and normalize asset information.
Flag shadow IT, BYOD and legacy systems for board-level review.

Most importantly, tie visibility gaps to business impact: “We lack patch compliance data for X% of endpoints, which affects SLA delivery and regulatory posture.”

Closing the communication gap: What CISOs and boards must do

Forty percent of security teams say IT doesn’t understand their organization’s risk tolerance — that’s a cybersecurity governance red flag. The board cannot challenge, prioritize or allocate resources without clarity on business impact.

Under NIS2 regulations, the management body needs to exercise informed oversight. The remedy starts with the CISO translating exposures into scenarios the board recognizes:

“If we do not update those systems within 48 hours, there’s a very high probability of breach, and the health data of all our clients will be easy to extract. This will hurt our brand, create claims in court and stop our services for days.”

Strong briefings provide a time frame and tie investments to reductions in the top exposures (the exploits that would materially hurt revenue, safety or compliance).

Boards should insist on a compact list of priorities, agree on risk appetite in economic terms and revisit progress quarterly. Over time, that discipline replaces tool-centric updates with a shared narrative of how the attack surface is shrinking and resilience is improving.

Every board deck should answer these three simple questions:

What could go wrong that truly matters?
What are we doing about it?
How will we know it worked?

Anchor measurement to outcomes — time to isolate, time to recover and changes in the top-ten exposures — rather than raw patch or alert counts. When discussing technical debt, attach a price tag: “Keeping this EOL cluster another quarter preserves functionality but adds €X expected loss unless we isolate and monitor it.” That is the language of governance NIS2 expects to see in minutes and in decisions.

Training the board: A NIS2 imperative

The board can only close the communications gap when they really know the subject. NIS2 codifies what many already recognize: the management body needs regular cybersecurity training to discharge its duties.

Effective programs are pragmatic: They brief directors on evolving threats (such as AI-enabled ransomware and compromised software supply chains), clarify staged reporting and potential liabilities and practice decisions through realistic table-top exercises.

Prioritize sessions that teach directors to read cyber metrics in business terms (e.g., what the exposure picture implies for continuity, customers and compliance) and how to interrogate the plan until it is credible.

Turn training into capability. Make board education a continuous competency, not a one-off seminar. Use short, focused modules that build fluency (e.g., one quarter on exposure prioritization, the next on supplier oversight and CVD, then one on incident reporting mechanics).

Base each session on a real scenario, like AI-assisted ransomware or a malicious vendor update and capture the specific decisions directors must make. Convert those decisions into concrete governance improvements (updated policies, contract clauses or metrics) so training shows traceable uplift rather than box-ticking.

Close the gap between intent and impact for NIS2-readiness

Ivanti’s research shows encouraging intent — boards talk about cybersecurity, budgets are growing and CISOs have a seat at the table. But, intent does not equal impact.

That same data reveals preparedness gaps for ransomware, stubborn silos that slow response and weaken posture, a long tail of end-of-life technology and opaque supply chain risk that keeps material exposure on the books.

NIS2 raises the bar from conversation to accountability: management bodies must ensure measures are proportionate, state of the art and effective — and they must prove it when incidents occur.

Organizations that close the communication gap, retire or isolate legacy systems on a schedule and replace questionnaire-only oversight with evidence and rehearsal will find they are not only compliant, but resilient.

Is Your Patch Process Hurting End Users’ Experience? Here’s How to Fix It

Tue, 23 Sep 2025 14:58:00 Z

Just one bad patch can cause key systems to fail, disrupting your teams and, ultimately, your customer experience.

While I was checking out at a supermarket self-service machine, the screen suddenly froze and then dreaded blue screen of death appeared. A nearby staff member quickly came over and, with a bit of a sigh, said it was the third time that day this happened. While I’ll never know for certain whether a patch was the only cause, businesses want to minimize these types of issues.

One bad patch can impact your organization, too. Imagine your customers unable to contact your client success team or your frontline workers unable to access critical data.

While you could delay patch deployment, you run the risk of a total company outage due to a ransomware breach or other cyberattack.

The reality is that vulnerability remediation requires never-ending vigilance. You can address many vulnerabilities through patch management, but without adequate testing, critical systems and business services can get disrupted, affecting your teams and, in short order, reducing profitability.

Let’s take a look at how poorly managed patch updates can cause major disruptions. I’ll also discuss how a ring-based deployment strategy, combined with user surveys after each stage of the rollout, provides a safer and smarter way to mitigate vulnerabilities and outages.

Patch deployment: The need for speed

Regular patch management is one the best ways to secure your data and services. Security frameworks provide best practices, guidance and standards for customers to adhere to; for example, CIS Controls v8 guides teams to apply critical patches in less than seven days, and remediation must occur faster (within 24 hours) if a vulnerability is part of the CISA KEV list.

Organizations comply with these (and the other controls) to reduce risk of catastrophic breaches, maintain regulatory compliance and reduction cyber insurance costs.

In addition, vulnerability exploitation surged by 34% compared to last year (2024). Ransomware-as-a-Service (RaaS) has transformed cybercrime into a subscription economy, where low-skilled attackers can rent powerful ransomware kits from dark web marketplaces. This model dramatically lowered the barrier to entry, fueling a surge in global attacks and extortion attempts.

Now, with the integration of artificial intelligence, threat actors can automate reconnaissance in attempts to locate vulnerable targets at speed. All this makes proper patch management more essential than ever. When a critically rated vulnerability is identified (e.g., a zero day), deployment speed is crucial — but you must balance it with control. Ring deployment acts as an early warning system by rolling out updates in controlled waves.

Ring deployment for secure, scalable patch management

Ring deployment for patch management is a phased approach to rolling out software updates or patches across an organization. Devices are grouped into “rings” based on risk tolerance and criticality. This tried-and-true method helps reduce the risk of widespread disruption by detecting and resolving issues early in the deployment cycle.

And it gets even more powerful when you combine it with telemetry from devices and user sentiment. Direct user feedback during each ring allows IT to deploy at scale and maintain speed.

Combine user surveys and ring deployment to stay ahead of potential patch issues

It’s that time again: your organization is rolling out a patch to address a critical vulnerability.

You start with a ring-based deployment — a small group of IT staff and early adopters gets the update first. This initial phase helps validate that the patch installs cleanly without breaking core systems. Once it clears that stage, the patch moves to the next ring — maybe 500 general users from non-critical departments.

With this quantity and diversity of devices, user feedback helps you determine if the overall update worked and can even help you identify when downstream issues may occur before you move onto the next ring.

In your user surveys, collect feedback on:

System performance.
Usability.
Post-patch issues experienced by users in the current ring.

This way, you can gate your rollout — if survey results reveal a high rate of negative feedback or unresolved issues, pause the deployment for investigation and remediation. Open support tickets, gather device logs and alert your IT team.

This feedback loop ensures that only stable, well-received updates advance, reinforcing trust in IT processes and reducing the risk of vulnerabilities making it into high-impact environments, like your customer care center.

Scale your security posture and minimize disruptions with ring deployment and user feedback

When you combine ring deployment and patch experience user surveys, your organization can successfully deploy all critical patches in a timely manner, meeting both security best practices and compliance requirements. Systems are secure, risks from known vulnerabilities are reduced and auditors can see evidence of a timely, controlled process.

Ivanti Neurons for Patch Management helps you make patch deployment a seamless process by surveying users directly in the patch experience, automatically pausing rollouts if survey results reveal issues or users respond negatively.

Remember, patching is never truly finished—new vulnerabilities are disclosed daily, and the next cycle of updates is already on the horizon. Staying secure means repeating this process consistently, ensuring that each patch cycle closes today’s risks while preparing for tomorrow’s threats.

Schrödinger’s Vulnerability: Why Continuous Vulnerability Management Isn’t Optional

Wed, 17 Sep 2025 13:00:01 Z

The classic thought experiment known as Schrödinger’s Cat imagines a cat that’s simultaneously alive and dead; that is, until someone opens the box. In other words, it’s both alive and dead until the point that we can confirm the truth.

Now, swap the cat for software vulnerabilities, and you’ve got a fantastic analogy for what happens in today’s security environment. Teams won’t know a vulnerability exists until it’s discovered and in the worst cases, until it’s already being exploited.

That uncertainty is what I call Schrödinger’s vulnerability.

It’s the gap between the assumption of safety and the reality of exposure. And it’s a gap that traditional vulnerability management practices alone can’t bridge.

With threat actors leveraging automation and AI to enhance the speed and scale of their attacks, the time between the discovery of a vulnerability and exploitation is shrinking. Organizations can’t afford to waste time identifying and patching vulnerabilities.

Traditional patching methods are on a fixed cadence – once a month or once a week – but this approach is out of touch with the realities of modern threats.

Organizations need to branch out from relying just on reactive, scheduled patch management and remediation cycles. It’s time we shift our mindset to an always-on, comprehensive way of understanding a potential vulnerability – even before we know that the vulnerability exists.

The Patch Tuesday problem: real-world threats move faster

Let’s start with what we all know: Patch Tuesday is predictable. Patch Tuesday remains an important practice in helping security teams prioritize their updates and remediate newly-identified vulnerabilities. Leading tech companies like Microsoft, Apple and Ivanti itself release their updates and patches on a regular cycle, giving IT and security teams time to prepare their own maintenance cycles.

However, the problem is that many vulnerabilities aren't so predictable.

For example, popular third-party applications such as Adobe, Mozilla and Google are continuously releasing updates to common applications — such as browsers — that we all use on a daily basis.

For organizations only anchored to a monthly maintenance schedule, this can create a dangerous delay. Each time you “close the box” and wait for the next patch window, you leave a 29-day exposure gap wide open.

Consider what happened in the spring months of 2025: in the span of five weeks, Chrome, Edge and Firefox each identified zero-day vulnerabilities that required immediate attention:

Two Firefox vulnerabilities publicly exploited at the Pwn2Own hacker competition
An actively exploited zero-day in Chrome and its sibling browser, Edge
Multiple rapid-fire CVE disclosures demanding swift action

Modern cyber attackers can reverse-engineer newly released patches to uncover the underlying vulnerability, weaponize proof-of-concept exploits and launch automated attacks.

Once a vulnerability is publicly disclosed, you enter a critical window to resolve the issue before threat actors can take advantage of it. In fact, the June 2025 zero-day in Chrome (CVE-2025–5419) was actively exploited in the wild upon patch release, underscoring how quickly adversaries can weaponize a disclosed flaw.

To extend our Schrödinger’s analogy: vulnerability management is like herding cats. And as anyone who’s tried to herd cats knows, it’s a 24/7, round-the-clock job. In other words, continuous vulnerability management is even more crucial now than before.

The IT burden: continuous releases and compressed SLAs

Threat velocity is only half the challenge. As more vendors shift to continuous release cycles, it forces security teams to shrink SLAs, sometimes dramatically. The result is often “smoke-test validation”, confirming a patch has been installed without fully checking its impact. That’s how bugs, compatibility issues and missed dependencies slip through. You’re increasing operational risk even when trying to reduce security risk. It’s like peeking in the box to see if the cat’s breathing and missing the open window behind it.

IT teams are struggling to test, validate and deploy patches at that increased pace, according to Ivanti research. Nearly four out of 10 (39%) cybersecurity professionals find it a challenge to prioritize risk remediation and patch deployment, and 35% aren’t consistently able to maintain compliance when patching.

A different approach is needed. Teams need to be more proactive and continuous in their approach. This means establishing a mindset of exposure management to be more proactive.

Risk appetite: the starting point for exposure management

Every organization has a different tolerance threshold regarding risk. That’s your risk appetite. If you haven’t formally defined that in your teams, you can’t operationalize an effective response strategy.

That’s why continuous vulnerability management starts with a conversation across stakeholders. You must bring security ops, IT and business leadership to the table to address critical questions:

What level of exposure are we willing to tolerate?
How fast can we realistically respond to zero-day threats?
What's the financial, operational and reputational cost of being wrong?

The average cost of a ransomware incident is now reported as being upwards of $5 million. That’s no small sum, and especially for smaller organizations, the high costs may pose an existential threat to their business.

For enterprises, it’s more the brand damage and regulatory exposure where it stings the most.

No matter your size, these numbers demand a shift from measuring patching SLAs to actively managing exposure.

From cadence to coverage: tiered patch management framework

At Ivanti, we’ve operationalized this mindset through a flexible, layered policy framework within our Neurons for Patch Management platform. This starts with three policy tiers that align with real-world vulnerability response patterns:

1. Routine maintenance

This is your baseline: OS updates, scheduled, third-party patches, standard hygiene. While essential, it’s insufficient if it stands on its own. You’re keeping the lights on, but you’re not ready when a storm hits.

2. Priority updates

Browsers, collaboration tools and document apps change constantly, making them prime targets for exploitation. Because of the perpetual change and evolution of these apps, they require faster response cycles and purpose-built policies. We’ve created default configurations to help customers proactively manage these risk-prone applications with minimal friction.

3. Zero-Day response

Agility matters most here. When a zero-day is discovered and disclosed (or worse, exploited), you don’t have time to debate or argue about what to do in response. You need preconfigured, battle-tested policies that you can pivot to immediately and patch outside your normal cycle.

These three tiers running parallel to each other give organizations a starting point for moving beyond cadence-based patching. They operationalize the concept of risk appetite by matching prescribed response urgency to the nature of the threat.

Multilayered vulnerability management and continuous compliance

Not every system is perfect, though. What happens when something falls through the cracks?

Maybe an employee was on vacation. Maybe a system was turned off. Maybe a new device was integrated without the latest patches. These are the edge cases that create silent, persistent risk. These are your very own Schrödinger’s vulnerabilities.

To solve this requires a fourth remediation track: Continuous Compliance.

This task runs in the background. It monitors for devices that don’t meet your latest patching baseline from routine to zero-day. When it finds gaps, it closes them automatically. It’s like a bank’s vault automatically locking shut when thieves trigger the alarm.

There’s no need to wait for the next Patch Tuesday or have someone manually watch the dashboard 24/7. This is where true continuous vulnerability management takes shape. Ongoing coverage (and security) rather than manual reaction.

Shrinking the noise: focus on what matters

There’s another critical benefit here: dramatically reducing the volume of noise your security teams have to triage.

Take July’s Patch Tuesday. Microsoft released patches for 104 CVEs. Let’s do the math: say you have 3,000 Windows 11 machines in your user base. That means more than 300,000 “findings” for your vulnerability scanner.

But here’s the thing: if your exposure management program is doing its job, 99% of those findings are already addressed and accounted for in your routine maintenance, priority updates or in your zero-day response tasks. No more needing to parse through mountains of redundant alerts – your team can now home in on what needs real attention, including gaps, anomalies and uncompliant systems.

That’s how you move from reactive alert fatigue to active risk reduction.

From patch management to preparedness

This, ultimately, is a mindset shift. You’re moving from a reactive model to a proactive one. You’re shifting from waiting for vulnerabilities to surface and deciding what to do about them, to responding with predefined and automated processes firmly in place.

That’s the difference between simply patching and being prepared. It matters more now than ever, with CVE counts rising and threat actors faster, smarter and better resourced.

Regulatory expectations are also growing. Whether it’s SEC disclosure rules, National Institute of Standards and Technology (NIST) frameworks or industry-specific compliance mandates, the bar for “reasonable security” is climbing.

The baseline has changed: it’s no longer patch and react. It’s continuous vulnerability management.

Not falling for Schrödinger’s vulnerability

Back to the cat. The whole point of Schrödinger’s Cat thought experiment is that uncertainty persists until you look.

That’s fun in concept, but it’s dangerous when you apply that mentality to cybersecurity. You can’t just hope you won’t get hit — you must manage risk through continuous monitoring, patching and enforcing.

With the right measures in place, you’re not opening the box wondering if a vulnerability is “alive” or not. You’ve already taken steps to keep it safe. You can open with confidence and then shut the window of exposure before it even becomes an open door.

Discover more best practices to elevate your current patching and remediation efforts to a proactive, high-performing security strategy in our full Risk-Based Patch Prioritization Report.

September 2025 Patch Tuesday

Tue, 09 Sep 2025 21:28:36 Z

The days leading into September Patch Tuesday include a bit of chaos from a pair of actively exploited Android CVEs (CVE-2025-38352, CVE-2025-48543), a zero day in WhatsApp (CVE-2025-55177), another zero day in WinRAR (CVE-2025-8088), and a major supply chain attack through the Drift AI Chat Agent exposing Salesforce customers data.

The good news is Microsoft only has a pair of publicly disclosed vulnerabilities (CVE-2025-55234, CVE-2024-21907) out of 81 total CVEs resolved this month, making this about as close to a calm Patch Tuesday as we can hope for.

The Windows OS and Office updates are rated Critical this month, putting those as the highest priority, but with no zero-day exploits, this month should be focused on routine maintenance from a Microsoft perspective.

Microsoft’s publicly disclosed vulnerabilities

Microsoft has resolved an Elevation of Privilege vulnerability in Windows SMB (CVE-2025-55234), which Microsoft has confirmed is publicly disclosed. Microsoft rates the CVE as Important, and it has a CVSS v3.1 score of 8.8 and affects all Windows OS editions. The code maturity is unproven, which would indicate no code samples have been disclosed. A risk-based prioritization methodology would warrant treating this as Important.

Microsoft has resolved an Improper Handling of Exceptional Conditions vulnerability in Newtonsoft.Json (CVE-2024-21907), which Microsoft has confirmed is publicly disclosed. The CVE is unrated and affects SQL Server 2016, 2017 and 2019. Depending on the usage of the library, an unauthenticated and remote attacker may be able to cause the denial-of-service condition. A risk-based prioritization methodology would warrant treating this as Important.

Third-party vulnerabilities

Adobe has released nine updates resolving 22 CVEs, 12 of which are rated Critical. The products affected include Adobe Acrobat Reader, After Effects, Premiere Pro, Commerce, Substance 3D Viewer, Experience Manager, Dreamweaver, 3D Substance Modeler and ColdFusion. Adobe has rated the ColdFusion update as a priority one and Commerce as a priority two. The other seven updates are rated priority three.

Ivanti security advisories

Ivanti has released two updates for September Patch Tuesday resolving a total of 13 CVEs. The affected products include Ivanti Connect Secure and Policy Secure and Ivanti EPM.

For more details, you can view the updates and information provided in the September Security Update on the Ivanti blog.

September update priorities

With no zero-days released on Patch Tuesday, the updates this month are predominantly low risk. Ensure you have the zero days leading up to Patch Tuesday in hand, and plan to deploy the Microsoft and Adobe updates through your regular maintenance activities this month.