CSOonline

Anthropic only released its latest large language model, Claude Opus 4.6, on Thursday, but it has already been using it behind the scenes to identify zero-day vulnerabilities in open-source software. In the trial, it put Claude inside a virtual machine with access to the latest versions of open source projects, and provided it with a range of standard utilities and vulnerability analysis tools, but no instructions on how to use them nor how specifically to identify vulnerabilities. Despite this lack of guidance, Opus 4.6 managed to identify a 500 high-severity vulnerabilities. Anthropic staff are validating the findings before reporting the bugs to their developers to ensure the LLM was not hallucinating or reporting false positives, according to company blog post. “AI language models are already capable of identifying novel vulnerabilities, and may soon exceed the speed and scale of even expert human researchers,” it said. Anthropic may be keen to improve its reputation in the software security industry, given how its software has already been used to automate attacks. Other companies are already using AI to handle bug hunting and this is further evidence of the possibilities. But some software developers are overwhelmed by the number of poor-quality AI-generated bug reports, with at least one shutting its bug-bounty program because of abuse by AI-accelerated bug hunters. View the full article

A particularly insidious phishing campaign is disguising malware pretending to be ordinary PDF documents behind links to virtual hard disks. Because workers are used to receiving purchase orders or invoices in the PDF format, they are likely to open the malicious files unthinkingly, enabling the malware they contain — in this case AsyncRAT, a remote-access Trojan — to take control of company computers. The emails in this phishing campaign don’t attach a document directly but include links to a file hosted on IPFS (InterPlanetary File System), a decentralized storage network increasingly used by cybercriminals as it can be accessed through normal web gateways. Those files are virtual hard disks that, when opened, mount as a local disk, bypassing some Windows security features. Inside the disk is a Windows Script File (WSF) purporting to be the expected PDF: When the user opens it, Windows executes the code in the file thus leaving the computer open to exploitation by remote users. To protect themselves, organizations and PC users should set Windows to show file extensions, MalwareBytes Labs advised in a blog post, crediting Securonix with discovering the Dead#Vax malware campaign. This article first appeared on Computerworld. View the full article

The Chief Information Security Officer role has become one of the most precarious positions in the C-suite. According to a Hitch Partners study, the average CISO tenure is 39 months — a timeframe that reflects the intense pressure and high stakes of the position. With 77% of CISOs fearing dismissal after a major breach, the margin for error continues to shrink. The IANS/Artico Search CISO Compensation Report reveals that turnover rates hit 15% in 2025, up from 11% in 2024. Even a 6.7% compensation increase hasn’t slowed the exodus. The CISO role has evolved from technical expert to strategic business executive — a shift many security leaders struggle to navigate. Rising personal liability under regulatory frameworks, persistent budget constraints, and an increasingly sophisticated threat landscape have converged to create an environment where even experienced CISOs find their positions at risk. This article examines the ten most common reasons CISOs lost their jobs in 2025 and provides mitigation strategies to help security leaders protect their positions. The data comes from recent industry research, including surveys of 550+ CISOs, analysis of security budget trends, and interviews with executive recruiters who’ve witnessed countless CISO departures. 1. Failure to prevent or manage major breaches The most direct path to dismissal remains the inability to prevent or effectively respond to significant cybersecurity incidents. Organizations operate under a “one-throat-to-choke” mentality, and when a breach occurs, the CISO becomes the obvious target for accountability. According to recent data , 77% of CISOs believe a major breach will cost them their position. High-profile incidents consistently result in leadership changes, regardless of whether the CISO had adequate resources or executive support before the incident. Mitigation strategy: A comprehensive incident response plan with clear communication protocols and regular tabletop exercises forms the foundation of effective breach management. Documented risk assessments shared with the board create a paper trail that demonstrates due diligence. When leadership understands the risks flagged by the security team and the resources requested, they’re less likely to assign blame to the CISO when incidents occur. 2. Poor communication with the board and C-suite Technical expertise alone no longer suffices in the modern CISO role. Security leaders who fail to translate cyber risks into business impact quickly lose credibility with decision-makers who control budgets and strategic direction. When security leaders present endless technical details without connecting them to revenue loss, regulatory fines, or competitive disadvantage, boards tune out. This communication gap creates a dangerous disconnect where executives underestimate risks and underinvest in cybersecurity. Lavonne Burke, VP of Legal, Global Security, IT & AI at Dell, succinctly framed the solution during the Cyber Risk Virtual Summit 2025: “CISOs must translate risk into a language the board understands. Instead of talking about encryption, explain how it prevents financial and reputational loss.” Mitigation strategy: Effective CISOs frame every security discussion in business terms. Rather than reporting “critical vulnerabilities,” they explain potential financial impact, customer trust erosion, and regulatory consequences. Dashboards that show risk trends and tie security metrics to business objectives the board already tracks prove far more effective than technical reports. 3. Inadequate compliance and governance management Based on research by Ponemon Institute and GlobalSCAPE, regulatory frameworks have evolved from guidelines to legal requirements with teeth. Non-compliance costs organizations 2.7 times more than maintaining compliance, and CISOs increasingly face personal liability under frameworks like GDPR, HIPAA, and emerging AI regulations. Regulatory frameworks have evolved from guidelines to legal requirements with teeth. Non-compliance costs organizations 2.7 times more than maintaining compliance, and CISOs increasingly face personal liability under frameworks like GDPR, HIPAA, and emerging AI regulations. The Meta (Facebook) €1.2 billion GDPR fine serves as a sobering reminder that regulators impose penalties that materially impact business operations — and no company, regardless of size or market position, is exempt from enforcement. CISOs who treat compliance as a checkbox exercise put both their organizations and careers at risk. Mitigation strategy: A robust governance framework maps security controls to specific regulatory requirements. Detailed audit trails demonstrating due diligence, regular compliance assessments, and quarterly reports to the board on compliance posture create the documentation necessary to demonstrate organizational commitment to regulatory adherence. Modern password management solutions like Passwork provide the audit trails and access logs that compliance frameworks demand, giving CISOs concrete evidence of credential governance during audits. 4. Lack of business acumen and strategic alignment Security leaders who position themselves as cost centers rather than business enablers struggle to maintain executive support. In 2026, boards expect CISOs to understand how security decisions impact market share, customer acquisition, and competitive positioning. Adam Fletcher, CISO, Blackstone: “Cybersecurity isn’t about avoiding risk — it’s about managing it intelligently. The future belongs to leaders who make cyber resilience a competitive advantage.” When security becomes a barrier to business initiatives rather than a framework for safe innovation, executives start questioning the CISO’s value. Leaders who can’t articulate how cybersecurity investments protect and enable revenue growth find themselves sidelined during strategic discussions. Mitigation strategy: Successful CISOs develop a deep understanding of their organization’s business model, revenue streams, and competitive landscape. Early participation in product development discussions allows security leaders to offer guidance that accelerates rather than blocks initiatives. Positioning security as a shared responsibility that enables business objectives transforms the function from cost center to strategic partner. 5. Weak password policies and credential management Credential-based attacks remain one of the most common breach vectors, yet many organizations still rely on outdated password policies and inadequate credential management. When breaches trace back to compromised passwords, CISOs face difficult questions about why basic security hygiene wasn’t enforced. Human error in password management creates cascading vulnerabilities. Employees reuse passwords across systems, share credentials through insecure channels, and store sensitive access information in plaintext documents. These practices create entry points that attackers exploit with alarming efficiency. This is where modern enterprise password managers like Passwork become essential. By enforcing strong, unique passwords and providing a centralized vault, they directly address the root cause of many credential-based breaches. These solutions eliminate the friction that leads employees to adopt risky workarounds while giving security teams visibility into credential usage across the organization. Mitigation strategy: Enterprise password management solutions that combine strong password generation, secure sharing capabilities, and comprehensive audit trails address the root cause of credential-based breaches. Pairing this technology with clear policies and regular training builds a culture where credential security becomes second nature. 6. High stress, burnout, and leadership fatigue The 39-month average CISO tenure reflects more than just dismissals. Many security leaders resign under the weight of impossible expectations and relentless pressure. Research shows 84% of CISOs experience high stress levels, with 48% reporting significant mental health impacts. Burnout degrades decision-making quality, reduces strategic thinking capacity, and damages relationships with colleagues. When exhausted leaders become reactive rather than proactive, their performance suffers in ways that eventually lead to dismissal or resignation. Mitigation strategy: Establishing boundaries and delegating effectively protects against burnout. A strong security team capable of handling day-to-day operations allows the CISO to focus on strategic initiatives. Sustainable performance requires protecting mental health as vigilantly as protecting organizational systems. 7. Budget mismanagement and failure to demonstrate ROI Security budgets face constant scrutiny, and CISOs who can’t build compelling business cases for investments struggle to secure necessary resources. When security spending appears disconnected from measurable outcomes, CFOs and boards question whether they’re getting value for their investment. The challenge intensifies when CISOs request budget increases after incidents occur. Executives reasonably ask why previous investments didn’t prevent the breach, creating a credibility gap that’s difficult to overcome. Mitigation strategy: A risk-based budgeting approach quantifies potential losses from different threat scenarios, creating compelling business cases for security investments. Tracking and reporting metrics that demonstrate how security investments reduce risk exposure, prevent incidents, and enable business growth establishes clear ROI that resonates with financial decision-makers. When presenting budget requests, CISOs can point to concrete improvements like reduced credential-related incidents after implementing enterprise password management — measurable outcomes that CFOs understand. 8. Insufficient staff training and cybersecurity culture Technology alone can’t secure an organization. When employees don’t understand their role in security or view it as someone else’s problem, even sophisticated defenses fail. CISOs who neglect culture-building create environments where security policies are circumvented rather than embraced. A divided security culture where different departments operate under inconsistent standards creates gaps that attackers exploit. When security feels like an impediment rather than a shared responsibility, employees find workarounds that introduce vulnerabilities. Mitigation strategy: Effective security awareness programs go beyond annual compliance training. Engaging, role-specific education helps employees understand threats relevant to their work. Security champions in each department who advocate for best practices within their teams create a distributed defense model that scales across the organization. 9. Overlooking insider threats While external attacks dominate headlines, insider threats represent a significant and often underestimated risk. Whether malicious or accidental, employees with legitimate access can cause devastating damage that’s difficult to detect and prevent. Robust password management solutions provide detailed audit trails that help identify unusual access patterns without invasive monitoring. When you can track who accessed what information and when, investigating potential insider incidents becomes significantly more efficient. Mitigation strategy: Least-privilege access controls limit employee access based on role requirements, reducing the potential impact of both malicious and accidental insider actions. Behavioral analytics identify anomalous activity patterns that warrant investigation. Comprehensive logs of sensitive data access, coupled with transparency about monitoring practices, balance security needs with employee trust. 10. Resistance to change and lack of innovation The threat landscape evolves constantly, and CISOs who cling to outdated methodologies quickly become ineffective. In 2025, AI-driven attacks, quantum computing threats, and sophisticated social engineering require security leaders who embrace innovation rather than resist it. Organizations implementing Zero Trust architectures, AI-powered threat detection, and cloud-native security models need CISOs who understand these technologies and can guide their adoption. Leaders who view new approaches with skepticism or who lack curiosity about emerging threats lose relevance rapidly. Mitigation strategy: Continuous learning about emerging threats and security technologies keeps security leaders relevant in a rapidly evolving landscape. Industry conferences, peer networks, and relationships with vendors provide insight into coming innovations. A culture of experimentation within the security team encourages adaptation and prevents organizational stagnation. Building a sustainable security leadership career The CISO role continues to evolve from a technical position into a strategic business function that requires equal parts security expertise, business acumen, and leadership capability. Success in 2026 requires thinking beyond traditional security operations to become a business leader who specializes in security. The future belongs to security leaders who embrace proactive strategies, leverage modern tools like enterprise password managers to address foundational vulnerabilities, and position security as a business enabler. Start with the basics: credential management remains one of the most exploited attack vectors, yet it’s also one of the most solvable problems. Passwork eliminates password-related risks while providing the audit trails and governance controls that compliance frameworks demand — giving CISOs both improved security posture and the documentation to prove it. By addressing these ten common failure points systematically, you can build a sustainable career that survives the intense pressures of the modern CISO role. Ready to address credential vulnerabilities in your organization? Passwork offers a zero-risk transition: free migration assistance and implementation, pay nothing while your current subscription runs — then get 20% off Passwork when you’re ready to switch. See how centralized password management, detailed audit logs, and secure credential sharing can strengthen your security posture. View the full article

The Cybersecurity and Infrastructure Security Agency has given federal agencies 18 months to remove all end-of-support edge devices from their networks, escalating its response to what security researchers describe as a fundamental shift in nation-state attack tactics, where attackers exploit network infrastructure rather than endpoints. The binding operational directive, BOD 26-02, requires Federal Civilian Executive Branch (FCEB) agencies to inventory, update where possible, and ultimately replace firewalls, routers, VPN gateways, load balancers, and network security appliances that no longer receive vendor security patches. CISA warned that the threat from these unsupported devices is “substantial and constant.” “Unsupported devices pose a serious risk to federal systems and should never remain on enterprise networks,” CISA Acting Director Madhu Gottumukkala said in the directive. The directive requires FCEB agencies to immediately update any edge device running outdated software to vendor-supported versions where possible. Within three months, agencies must inventory all end-of-support devices using CISA’s EOS Edge Device List and report findings. Within 12 months, agencies must begin removing devices that have reached end-of-support dates. The 18-month deadline requires all unsupported edge devices to be permanently removed and replaced. Why edge devices became prime targets “Edge devices differ fundamentally from traditional IT assets, as they are often end of support, custom, OEM and process dependent,” Avinash Dev Nagumanthri, director analyst at Gartner, told CSO. “This makes discovery, patching, and replacement difficult under tight budgets while maintaining uptime.” Network edge devices have become one of the top initial access vectors for state-affiliated cyberespionage groups and ransomware gangs. Research shows a dramatic increase in edge device exploitation, with network edge vulnerabilities seeing an 8x increase in exploitation activity. The 2025 Mandiant M-Trends report found that 21% of ransomware attacks featured vulnerability exploitation as the initial access vector. CISA has documented nation-state campaigns targeting devices from Cisco, Fortinet, Palo Alto Networks, Ivanti, Juniper, and other vendors. The agency noted that these devices have become attractive targets because of their position at the network boundary, integration with identity management systems, and privileged access for lateral movement. Once compromised, they enable threat actors to intercept network traffic, harvest credentials, and exfiltrate sensitive data while evading traditional endpoint detection. Nagumanthri noted that edge devices protecting critical infrastructure can have physical impacts when compromised, putting high-value systems in sectors like water and transportation at risk. “Nation-state actors are increasingly exploiting edge devices as entry points into infrastructure, threatening critical private sector operations.” The directive follows two recent emergency directives. In September, CISA issued Emergency Directive 25-03 after threat actors exploited zero-day vulnerabilities in Cisco Adaptive Security Appliances, deploying persistent malware that survived reboots. In October, another emergency directive followed the compromise of F5 Networks’ development environment, where attackers exfiltrated BIG-IP source code. Implementation hurdles Sunil Varkey, advisor at Beagle Security, warns of implementation complexities. “The operational reality of removing legacy systems is not straightforward,” Varkey said. “Legacy devices continue to exist not by design, but by necessity.” He pointed to orphaned systems that remain live and embedded in workflows but lack clear ownership, and operational technology environments where newer hardware or software versions are not available, compatible, or certified. The process requires asset discovery, risk assessment, procurement, configuration redesign, data migration, testing, and managed cutovers to avoid service disruption. “A common challenge will be the presence of ‘orphaned’ or ‘ghost’ systems — devices that are live, embedded in workflows, but no longer clearly owned,” Varkey said. “These systems often persist because ‘they’ve always worked,’ even when no one fully understands their function.” Private sector implications While the directive applies only to federal civilian agencies, CISA strongly encourages private sector organizations to adopt similar measures. The exploitation campaigns targeting federal networks pose equivalent risks to critical infrastructure and commercial enterprises. Nagumanthri recommended that organizations treat edge and cyber-physical systems as Tier-0 assets, enforce strong authentication, implement network segmentation, require vendor-supported firmware updates, and centralize logging to limit blast radius. For the private sector, he advocated structured lifecycle management with secure-by-design hardware, continuous monitoring, and controlled updates with rollback capabilities. Varkey saw the directive as a catalyst for modernization beyond compliance. “While the short-term impact will be challenging, the outcome is a more secure, accountable, and defensible infrastructure — one better aligned with today’s threat realities and tomorrow’s operational needs.” View the full article

Cloud security company Zscaler has announced the acquisition of SquareX, a Singapore-based browser detection and response (BDR) technology startup. The deal will enable Zscaler to extend its Zero Trust Exchange capabilities directly into standard web browsers, across both managed and unmanaged devices. With Zscaler Private Access (ZPA), the company has been assisting enterprises adopt zero trust architecture using a lightweight agent. The SquareX acquisition is expected to further strengthen Zscaler’s ability to deliver security directly within commonly used browsers through lightweight extensions, eliminating the need for a separate enterprise browser. The acquisition will assist in enabling posture-like security and protection against advanced spear-phishing and identity-based attacks right into the user’s existing workflow, stated Jay Chaudhry, CEO, chairman, and founder of Zscaler, in his LinkedIn post. Browsers, the new frontier for attacks Traditionally treated as a mere gateway to the internet, web browsers are now at the center of enterprise activity, being widely used for SaaS applications, cloud services, and increasingly for generative AI tools. As employees upload, copy, and share sensitive data through browser sessions, this growing reliance has also opened new avenues for security risks. “Most security stacks protect either the application, the endpoint, or the network. The browser is, unfortunately, the blind spot in between. There are traditional ways of dealing with the issue, but often at too great a risk, or as a result of too limiting an approach,” said Devroop Dhar, co-founder and MD at Primus Partners. SquareX assists by allowing any browser on any device to function more like a secure enterprise browser using a lightweight, extension-based approach. “This extension becomes a kind of runtime enforcement agent, offering session-specific controls such as browser-based DLP, dynamic content isolation, real-time monitoring of user behaviour, and targeted security enforcement depending on risk levels and session context,” said Sanchit Vir Gogia, CEO and chief analyst at Greyhound Research. SquareX’s approach also blocks sensitive data from being pasted into public AI tools, flags suspicious prompts, or limits interactions based on user role and data sensitivity, Dhar said. This is so important because AI misuse is rarely malicious, it is accidental. Browser-native security is better suited to prevent mistakes before they turn into incidents. SquareX extension-based security can be integrated with most commonly used web browsers, including Chrome, Edge, Firefox and Safari, allowing employees to continue using their preferred browser without requiring enterprises to deploy or manage yet another dedicated security tool. A win-win for customers? Zscaler has acknowledged that browser runtime behaviour was a missing piece in its zero-trust security, and having SquareX solution in its portfolio can help fill the gap, noted Gogia. For Zscaler customers, this acquisition would mean browser security is no longer an afterthought or a separate tool to evaluate but a native part of the platform. “It reduces reliance on legacy access methods like VPN and VDI, especially for external users. It also gives Zscaler the ability to unify policy enforcement across network access, app usage, and now browser behaviour. Zscaler customers will be able to apply in-session controls to activities that were previously invisible, such as clipboard actions, extension behaviour, or AI prompt submission. They also gain options for session isolation, file download inspection, and least-privilege app access via browser,” added Gogia. On the other hand, for SquareX customers, this means scale and integration. Vivek Ramachandran, founder and CEO of SquareX, confirmed in a blog post that customer deployments and investments will be protected, and over time, they will benefit from tighter integration with Zscaler services, expanded analytics, and more robust, risk-based controls across managed and unmanaged devices. In both instances, the customer benefits from improved alignment between access, behaviour, and enforcement approaches, stated Dhar. Different roads to browser security Of late, leading cybersecurity companies have been strengthening their product portfolios by investing in and acquiring specialized browser security firms. This is an indication that they now see browser-native security as strategic rather than optional. For instance, in January this year, CrowdStrike acquired Israel-based Seraphic Security, a browser runtime security company, which it plans to integrate into the Falcon platform. For CISOs, the concern has shifted from the security of the browser to where the security of the browser should be located. Dhar explained in the case of Zscaler’s move with SquareX, the strategy is to integrate browser controls with its access component of Zscaler zero trust. That’s security beyond granting access. However, in the case of the acquisition by CrowdStrike involving Seraphic, the strategy falls under endpoint security as they extend the visibility of EDR solutions to include the browser. View the full article

khunkornStudio – shutterstock.com Forscher des Sicherheitsanbieters Sysdig haben einen Angriff aufgedeckt, bei dem kriminelle Angreifer eine AWS-Umgebung in weniger als acht Minuten vollständig kompromittieren konnten. Laut den Threat-Spezialisten nutzten die Bedrohungsakteure dabei eine Cloud-Fehlkonfiguration mit der Hilfe von Large Language Models (LLMs) aus, um den gesamten Angriffs-Lebenszyklus zu komprimieren – von Stunden auf wenige Minuten. „Sich gegen Angriffe dieser Art zu verteidigen, erfordert KI-fokussierte Technologien, die in der Lage sind Schlussfolgerungen zu ziehen und es ermöglichen, auf automatisierte Attacken mit der nötigen Geschwindigkeit zu reagieren“, meint Ram Varadarajan, CEO beim Plattformanbieter Acalvio. Vom Public Bucket zur Privilege Escalation Initial konnten sich die Cyberkriminellen laut den Sicherheitsforschern Zugriff verschaffen, indem sie gültige AWS-Anmeldedaten nutzten, die zuvor in öffentlichen S3Buckets offengelegt wurden. Diese enthielten auch KI-bezogene Daten, etwa Berechtigungen für die Interaktion mit Lambda und eingeschränkten Zugriff auf Amazon Bedrock. „Dieser Benutzer wurde wahrscheinlich mit der Intention erstellt, Bedrock-Tasks mit Lambda-Funktionen in der gesamten Umgebung zu automatisieren“, erklären die Sysdig-Forscher. Mit Lesezugriff auf die gesamte Umgebung hatten die Angreifer dann auch leichtes Spiel damit, sich einen Überblick über alle verfügbaren AWS-Dienste zu verschaffen und ihre Berechtigungen zu erweitern, indem sie eine existierende Lambda-Funktion modifizierten. Wie die Analyse der Sicherheitsforscher zeigt, weist der Lambda-Code Anzeichen auf, die darauf hindeuten, dass er per LLM generiert wurde , darunter ein umfassendes Exception Handling iterative Targeting-Logik und nicht-englische Kommentare. Laterale Bewegung, LLMjacking und GPU-Missbrauch Nachdem sich die Angreifer administrativen Zugriff verschafft hatten, bewegten sie sich lateral über 19 verschiedene AWS-Principals und erstellten neue Benutzerkonten, um ihre Aktivitäten auf verschiedene Identitäten zu verteilen. Dieser Ansatz ermöglichte den Angreifern Persistenz und erschwerte parallel die Detection, wie die Forscher in ihrem Bericht festhalten. Anschließend verlagerten die Hacker ihren Fokus auf Amazon Bedrock, ermittelten die verfügbaren Modelle und deaktivierten die Protokollierung von Modellaufrufen. Laut den Forschern wurden dann mehrere Foundation-Modelle aufgerufen , entsprechend dem Muster von „LLMjacking“. Zudem verwies der Code in Teilen auch auf nicht existierende Repositories und Ressourcen, was Sysdig auf LLM-Halluzinationen zurückführt. Im Anschluss missbrauchten die Angreifer schließlich auch noch Ressourcen. Demnach versuchten die Angreifer, High-End-GPU-Instanzen für Machine-Learning-Workloads zu starten. Während das bei den meisten Instanzen aufgrund von Kapazitätsbeschränkungen fehlschlug, konnten die Cyberkriminellen allerdings eine besonders kostspielige GPU-Instanz starten – inklusive Skripten, um CUDA zu installieren, Trainings-Frameworks bereitzustellen und ein öffentliches JupyterLab-Interface zu exponieren. Experten zufolge ist das Beunruhigendste an diesem Angriff nicht, dass KI eine neue Angriffstechnik ermöglicht hat. „Wenn man diesen Angriff auf das Wesentliche reduziert, ist das bahnbrechende nicht die Technik“, betont etwa Shane Barney, CISO bei Keeper Security. „Entscheidend ist die geringe Widerstandsfähigkeit der Umgebung, sobald der Angreifer legitimen Zugriff erhalten hat.“ Der Sicherheitsentscheider warnt davor, dass KI Reconnaissance, Privilege Testing und laterale Bewegungen durch das Netzwerk in einer besonders schnellen Sequenz komprimiert. Hierdurch werde die Pufferzeit, auf die sich die Verteidiger bislang traditionell verlassen hätten, eliminiert. Um das Risiko solcher Attacken zu verringern, empfehlen die Sysdig-Forscher, das Least-Privilege-Prinzip konsequent auf sämtliche IAM-Benutzer- und Lambda-Execution-Rollen anzuwenden. Darüber hinaus sollten sensible S3-Buckets niemals öffentlich zugänglich sein, warnt Sysdig. Die Research-Experten legen Unternehmen außerdem ans Herz die Lambda-Versionierung zu nutzen, die Protokollierung der Modellaufrufe in Bedrock zu aktivieren, und verdächtige, großangelegte Enumeration-Aktivitäten kritisch zu überprüfen. (jm/fm) View the full article

The longstanding assumption that tenure, performance metrics, or expressed commitment serve as reliable indicators of the trustworthiness of an employee persists across many sectors. Indeed, the great majority of personnel are loyal. But, while small, the percentage of those who aren’t is still well above zero. Moreover, this conflation of loyalty and security overlooks a fundamental reality: Loyalty is not a static trait, but a dynamic human response shaped by perceived fairness, personal circumstances, and organizational alignment. When grievances go unaddressed or external pressures mount, what appears as steadfast allegiance can quietly shift toward disaffection, resentment, or deliberate breaking of trust. A half-century of observed patterns In my more than 50 years of government, private sector, and journalistic endeavors, I have seen this pattern play out repeatedly. What begins as genuine commitment can erode under the weight of unmet expectations, financial strain, ideological differences, outside influences, or simply the passage of time in roles that demand constant vigilance. The insider who once seemed beyond reproach becomes the very vector through which sensitive data, intellectual property, or operational integrity is compromised. These are not isolated failures of vetting or technology; they are failures to recognize that loyalty is relational and conditional, not absolute. How the misread appears in practice Recent examples illustrate the point. In the US federal sphere, abrupt terminations under workforce reduction initiatives have left former employees with lingering access to sensitive systems, amplifying the potential for data exposure or retaliation. Corporate cases show a similar dynamic: engineers or executives who have spent years building institutional knowledge suddenly depart with proprietary information, motivated not by espionage but by opportunity or resentment. These incidents are not anomalies. They reflect a broader pattern in which subjective judgments of loyalty, what I have come to call “personal barometers,” exist. For example, colleague to colleague, “Janet loves this company, she’s been here 20 years” may be a consensus view, yet it is not accompanied by objective, consistent, and transparent measures. Personnel history blind spots Organizations have long operated under the belief that loyalty, once demonstrated, becomes a durable shield against insider risk. Extended tenure is rewarded with escalating access privileges, high performers are granted broader system rights without commensurate behavioral review, and verbal affirmations of commitment are taken at face value. Yet time and again patterns repeat. What begins as mutual confidence weakens not through dramatic betrayal but through subtle realignments in personal commitment. An employee who once identified strongly with the mission may begin to feel undervalued, overlooked for advancement, or weighed down by outside pressures. The organization, relying on its subjective gauge of past performance, fails to notice the change until the cow has bolted from the barn. These patterns are neither new nor rare. They reflect a systemic reluctance to treat loyalty as a living relationship that requires active maintenance and verification. The blind spot becomes visible Today we have a confluence of forces that will expose the limitations of assumptive loyalty models. Economic volatility, including persistent inflation, ongoing AI-driven job displacements, and workforce reductions, will heighten personal and professional stressors for employees at every level. Compounding the human element is the rapid emergence of AI agents as autonomous insiders. These systems, granted privileged access to sensitive data and decision-making workflows, introduce risks at machine speed: prompt misdirection, goal misalignment, or unintended exfiltration without human intent or oversight. We know AI agents are among the fastest-growing insider vectors, with autonomous capabilities outpacing traditional controls. Geopolitical tensions further amplify the threat. Nation-state actors and proxies increasingly exploit economic pressures and ideological divides to groom or coerce individuals, blurring the lines between personal discontent and hostile external influence. In critical sectors (transportation, finance, medical, energy) where elevated roles already receive greater scrutiny, the model proves resilient. Yet in less regulated environments, the absence of universal, consensual standards leaves organizations exposed. What was once a subtle misalignment becomes systemic exposure when human volatility meets machine autonomy and geopolitical opportunism. Parallels to AI poisoning and the dual crisis of trust These themes extend directly from an earlier column of mine, “AI poisoning and the CISO’s crisis of trust.” That discussion examined how poisoned training data undermines the foundational integrity of artificial intelligence systems, creating a crisis of confidence in the tools organizations increasingly depend upon. The parallel to human loyalty is clear: Just as corrupted inputs erode the reliability of AI outputs, unexamined or misread human loyalties erode the reliability of the individuals who design, operate, protect, and rely on those systems. In both domains, reactive remediation is insufficient. Trust must be rebuilt through deliberate, continuous verification rather than periodic assumptions. The CISO’s crisis of trust is therefore dual: architectural in the machine domain and relational in the human domain. Coherence across these domains, ensuring that human and machine behaviors remain aligned with organizational intent, then emerges as the essential principle for long-term resilience. The path forward The path forward lies in embracing consensual, tiered verification, where elevated responsibility demands greater scrutiny. Positions with access to crown jewels — sensitive data, financial systems, or personnel records — or executive ranks inherently require proportionately more oversight, as regulated sectors have shown. Professionals in these roles accept this as part of the terrain, with history demonstrating minimal talent loss when frameworks are transparent and supportive. Federal Trusted Workforce 2.0 provides a vital blueprint for the private sector. By 2026, with full implementation across government agencies, this program enrolls millions in continuous vetting, using automated record checks to review a plethora of risks in real-time and reducing reliance on periodic reviews. Private adaptations are feasible and essential: secure releases from key personnel for ongoing monitoring, mirroring TW 2.0’s supportive ethos without federal mandates. These measures are far less expensive than the multimillion-dollar costs of a single malicious insider event ($4.9M to $13.9M per incident per IBM/Mimecast 2025 analyses). Broader practices include pulse surveys and engagement tools to surface misalignment early, integrated HR reviews, and wellness interventions. Gartner indicates AI-integrated behavioral programs reduce employee-driven incidents by 40%. These investments are economical, scalable, and consensual, fostering mutual trust. The folly of equating loyalty with security must end. Through verifiable, human-centric vigilance, including consensual scrutiny scaled to responsibility, organizations can earn trust, not assume it, transforming vulnerabilities into resilience. In the era of zero trust, there should be no pushback in the adoption of “trust but verify” personnel policies. See also: Insider risk in an age of workforce volatility Coherence: Insider risk strategy’s new core principle View the full article

Mit der Zunahme von Cyberbedrohungen steigt auch die Zahl der Compliance-Rahmenwerke. So können CISOs diese Herausforderung bewältigen. Foto: Dapitart – shutterstock.com Die Anforderungen von Cybersicherheitsvorschriften können je nach Unternehmensgröße, Region, Branche, Datensensibilität und Programmreifegrad sehr unterschiedlich sein. Ein börsennotiertes Unternehmen hat beispielsweise keine andere Wahl, als mehrere Vorschriften einzuhalten sowie Risikobewertungen und Pläne für Abhilfemaßnahmen zu erstellen. Regierungsbehörden oder Unternehmen, die an Regierungsbehörden verkaufen, müssen bestimmte Compliance-Anforderungen des öffentlichen Sektors erfüllen. Banken, Organisationen des Gesundheitswesens, Infrastrukturunternehmen, E-Commerce-Firmen und andere Unternehmen haben jeweils eigene branchenspezifische Compliance-Regeln zu befolgen. Lesetipp: Sind Sie bereit fürs neue Kreditkarten-Regelwerk? Sicherheit ist nicht gleich Compliance Auch für Unternehmen, die nicht in eine dieser Kategorien fallen, kann es Gründe geben, warum sie bewährte Sicherheitspraktiken nachweisen müssen, zum Beispiel, wenn sie eine SOC-Zertifizierung anstreben oder eine Cyberversicherung beantragen. Umfassende Rahmenwerke für die Einhaltung von Cybersicherheitsvorschriften wie NIS-2 und ISO bieten allen Unternehmen Leitlinien, die sie befolgen können, sowie Strukturen für die Kommunikation der Ergebnisse. Aber: Nur, weil man die Vorschriften einhält, heißt das noch lange nicht, dass man auch sicher ist. Erfahrene Sicherheitsexperten betrachten die Einhaltung von Vorschriften als das absolute Minimum und gehen in ihren Empfehlungen weit über die erforderlichen Komponenten zum Schutz ihrer Unternehmen hinaus. Einhaltung der Vorschriften als Voraussetzung für Geschäftstätigkeit Ein Sicherheitsmanager kann zwar Investitionen und Praktiken für die Cybersicherheit empfehlen, um die Compliance-Anforderungen zu erfüllen, aber er ist nicht der letzte Entscheidungsträger. Eine wichtige Aufgabe des CISO besteht daher darin, das Risiko der Nichteinhaltung von Vorschriften zu kommunizieren und gemeinsam mit anderen Unternehmensleitern zu entscheiden, welche Initiativen Vorrang haben sollen. Das Risiko umfasst in diesem Zusammenhang nicht nur das technische, sondern auch das Geschäftsrisiko. Um Reibungsverluste zu vermeiden, ist es daher sinnvoll, den Mitarbeitern auch den geschäftlichen Nutzen einer konformen Cybersicherheit aufzuzeigen. Kosten-Nutzen-Abwägung Die Unternehmensführung muss dabei die Kosten und den Nutzen der Einhaltung von Vorschriften gegen die potenziellen Kosten der Nichteinhaltung abwägen. Angenommen ein Unternehmen erfüllt eine Best Practice für die Verwaltung von Berechtigungen nicht vollständig: Bei Nichteinhaltung der Vorschriften können die zugrunde liegenden Schwachstellen neben möglichen Klagen von Anteilseignern noch größere Auswirkungen auf das Unternehmen haben, einschließlich Ausfallzeiten, Ransomware-Zahlungen und Umsatzeinbußen. Die Erfüllung der Compliance-Anforderungen könnte hingegen einen geschäftlichen Nutzen bringen, beispielsweise durch schnellere Verkäufe, stärkere Partnerschaften oder niedrigere Cyberversicherungsraten. Wie CISOs Compliance-Rahmenwerke nutzen können CISOs können vorhandene Compliance-Frameworks als Methodik für Techniken und Prozesse verwenden, um sie in ihr Cybersicherheitsprogramm einzubauen. Zu ihren Aufgaben gehört es im Wesentlichen, über die Programmprioritäten zu informieren und eine “Einkaufsliste” für Lösungen zu erstellen, die sie unbedingt benötigen und die mit dem Programm, das sie aufbauen wollen, übereinstimmen. Aber es gibt auch einen Unterschied zwischen der Verwendung eines Compliance-Rahmenwerkes zur Steuerung eines fundierten Risikomanagements und der exakten Einhaltung von Vorschriften. Hier gilt es einen Balanceakt zu meistern und fallweise auch risikobasierte Entscheidungen zu treffen. CISOs brauchen Partner bei der Einhaltung von Vorschriften CISOs sitzen bei der Einhaltung von Vorschriften nicht allein im Boot. Sie müssen Partnerschaften mit Rechtsteams, Datenschutzbeauftragten und Prüfungs- oder Risikoausschüssen aufbauen, um die sich ändernden Compliance-Anforderungen zu verstehen und zu entscheiden, wie sie zu erfüllen sind. Manchmal verlangen diese internen Partner von den Sicherheitsteams, dass sie stärkere Kontrollen einführen, aber sie können auch auf die Bremse treten. So würden manche CISOs gerne das Verhalten ihrer Mitarbeiter detailliert überwachen, aber die Datenschutzgesetze verbieten dies und die Rechtsabteilung sorgt dafür, dass diese Gesetze eingehalten werden. Compliance-Teams erledigen viele Dinge für die Sicherheitsingenieure und -analysten, die weder die Zeit noch die Ressourcen dafür haben. Sie nehmen die Sicherheit in die Pflicht und überprüfen, ob die Kontrollen wie erwartet funktionieren. Sie fungieren quasi als Vermittler zwischen Sicherheitsteams, Aufsichtsbehörden und Prüfern, um die Einhaltung der Vorschriften nachzuweisen, sei es durch das Sammeln von Beweisen mittels manueller Sicherheitsfragebögen oder durch Technologieintegrationen. Für eine Zertifizierung im öffentlichen Sektor müssen beispielsweise die Sicherheitskontrollen überwacht, protokolliert und die Daten mindestens sechs Monate lang aufbewahrt werden, um nachzuweisen, dass alle Vorgaben erfüllt wurden. Lesetipp: Wie internationale Security Frameworks CISOs unterstützen Tools und Ressourcen zur Unterstützung der Einhaltung von Vorschriften Risikoregister sind hilfreich, um alle Beteiligten an einen Tisch zu bringen, indem sie alle Risiken dokumentieren und nach Prioritäten ordnen. Wenn alle Beteiligten die gleichen Informationen einsehen, können sie sich auf geeignete Maßnahmen einigen. Im Rahmen eines Risikomanagementprogramms werden Richtlinien, Standards und Verfahren regelmäßig überprüft und alle Änderungen vor ihrer Umsetzung genehmigt. Mithilfe von Tools wie Governance, Risk, and Compliance (GRC)-Systemen und kontinuierlicher Überwachung der Einhaltung von Vorschriften wie NIS-2 und ISO können Unternehmen laufende Sicherheitsaktivitäten verfolgen und die Ergebnisse melden. GRC-Systeme lassen sich mit SIEM-Lösungen verknüpfen, um Protokolle zu sammeln, durch die Kombination mit Schwachstellen-Scannern kann man nachzuweisen, dass Prüfungen durchgeführt wurden. Zusätzlich zu solchen Instrumenten verlassen sich viele Unternehmen auf Dritte, um die Einhaltung der Vorschriften zu bewerten. Diese können vor einer externen Prüfung ein internes Compliance-Audit durchführen, um sicherzustellen, dass es keine Überraschungen gibt, wenn die Aufsichtsbehörden vorbeikommen. Einmal erfüllen, auf viele anwenden Die meisten Unternehmen haben zahlreiche Compliance-Stellen, denen sie Rechenschaft ablegen müssen, sowie Cyberversicherungsanbieter, Kunden und Partner. Die Einhaltung von Vorschriften kann zwar eine Belastung sein, aber es gibt Techniken, um den Bewertungsprozess zu rationalisieren. Immerhin ist ein Großteil der gesetzlichen Anforderungen beinahe identisch. Orientieren sich CISOs beispielsweise an einem Rahmenwerk wie NIST, können sie überall die gleichen Verfahren anwenden. So sind zum Beispiel Anforderungen an das Privileged Access Management (PAM) wie Passwortmanagement, Multi-Faktor-Authentifizierung (MFA) und rollenbasierte Zugriffskontrollen in allen Compliance-Frameworks zu finden. Ausblick Letztlich ist die Einhaltung von Vorschriften ein fließender Bereich mit Anforderungen, die sich weiterentwickeln, um den sich ändernden Risikomustern und Geschäftsbedingungen Rechnung zu tragen. Es ist zu erwarten, dass die Sicherstellung der Compliance in Zukunft einen noch größeren Teil der Arbeit von CISOs ausmachen wird. Da die Branche mit immer größeren Bedrohungen konfrontiert ist, ist die Einhaltung von Vorschriften ein wichtiger Bestandteil eines strategischen und umfassenden Ansatzes für das Management von Cybersicherheitsrisiken. (jm) Lesetipp: Das fordert das neue KRITIS-Dachgesetz View the full article

Four security vulnerabilities have been found in the open source Ingress NGINX traffic controller that is extensively used by organizations in Kubernetes deployments. They can only be fixed by upgrading to the latest version. Of the four holes, two are more serious, because they carry CVSS scores of 8.8: CVE-2026-1580 is an improper input validation issue. If the Ingress NGINX controller is configured with a default custom-errors configuration that includes HTTP errors 401 or 403, and if the configured default custom-errors backend is defective and fails to respect the X-Code HTTP header, then an Ingress with the auth-url annotation may be accessed even when authentication fails. CVE-2026-24512 is a configuration injection vulnerability where the rules.http.paths.path Ingress field can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of secrets accessible to the controller. “This is a serious vulnerability,” commented Kellman Meghu, CTO of Canada’s DeepCove Cybersecurity, who has experience with Ingress NGINX. “If I could exploit it, I could get the Ingress gateway to create a path directly to internal resources. It’s like opening the insides that should never be exposed. Will that lead to further exposure or hacks? Probably, but in terms of impact, it’s a first step to gain access into the environment, and from there it could go further, the least of which would be disruption of services.” NGINX is a reverse proxy/load balancer that generally acts as the front-end web traffic receiver and directs it to the application service for data transformation. Ingress NGINX is a version used in Kubernetes as the controller for traffic coming into the infrastructure. It takes care of mapping traffic to pods of containers running jobs without exposing the pods themselves. Meghu says Ingress NGINX is the primary traffic entry point, and is effective due to its ability to reload its configuration on the fly, allowing it to adjust to changes inside a Kubernetes cluster. These vulnerabilities only affect Ingress NGINX versions 1.13.7 and below, and 1.14.3 and below, if they are installed on a Kubernetes cluster. The warning comes just weeks before, as announced at KubeCon in November, support for Ingress NGINX ends. Starting in March, the project will no longer receive active maintenance, security patches, or bug fixes. Experts have been urging Kubernetes administrators to shift to a new controller ever since. They recommend Kubernetes Gateway API as the standard for traffic management. Meghu notes it is vendor neutral and widely used. Other options are controllers such as Cilium Ingress, Traefik, or HAProxy Ingress. In addition to CVE-2026-24512, the other new vulnerabilities are CVE-2026-24513, considered by Meghu a low risk since an attacker needs to have a config containing specific errors to exploit, and CVE-2026-24514, which Meghu considers a medium risk. The controller could be subject to a denial of service if an attacker overwhelms it with requests. These are just the most recent issues with Ingress NGINX. Just over a year ago, researchers at Wiz discovered a group of holes dubbed IngressNightmare. They can allow unauthenticated users to inject malicious NGINX configurations and execute malicious code into the Ingress NGINX pod, potentially exposing all cluster secrets and leading to cluster takeover. Satnam Narang, senior staff research engineer at Tenable, told CSO that he considers the new holes less concerning than IngressNightmare, which he called a “toxic combination” that could result in cluster takeover. “While there’s nothing novel about [the new vulnerabilities], they serve as a stark reminder to all admins that if they haven’t started migrating, they need to start immediately, before Ingres NGINX is retired next month. Given its upcoming retirement, migration is the best strategy to mitigate these vulnerabilities.” View the full article

A new cyberespionage group that operates out of Asia has compromised 70 government and critical infrastructure organizations across 37 countries over the past year using a sophisticated toolset that combines phishing, exploitation kits, custom malware, Linux rootkits, web shells, and a variety of other tunneling and proxy tools. Researchers believe the group is expanding its activities and is conducting active reconnaissance on even more targets. “Between November and December 2025, we observed the group conducting active reconnaissance against government infrastructure associated with 155 countries,” researchers from security firm Palo Alto Networks said in a new report. Palo Alto tracks the group as TGR-STA-1030 (aka UNC6619) and believes it is based in Asia based on language settings, its preference for regional tooling, GMT+8 operating hours, and targeting that aligns with events in the region. The researchers, who have been tracking the group since February 2025, believe it has ties to a nation state. The group’s confirmed victims include national-level law enforcement and border control entities; ministries and departments of interior, foreign affairs, finance, trade, economy, immigration, mining, justice, and energy; elected officials and even a parliament’s infrastructure. The group has also targeted national telecommunications companies. “While this group might be pursuing espionage objectives, its methods, targets, and scale of operations are alarming, with potential long-term consequences for national security and key services,” Palo Alto’s researchers said. From phishing to exploits Palo Alto started tracking the group a year ago following a series of phishing campaigns directed at European governments that the company dubbed the Shadow Campaigns. The phishing emails posed as announcements about organizational changes in official institutions and were written in the language of their intended targets. The messages contained links that led to the download of a ZIP archive with a custom malware loader the researchers now call Diaoyu. This loader performs various checks to detect the presence of certain antivirus programs and to ascertain whether it is running in a sandbox. It then proceeds to download the Cobalt Strike implant from a GitHub repository. Cobalt Strike is a commercial penetration testing tool that has grown popular among attackers over the years. Although the group hasn’t been observed exploiting previously unknown vulnerabilities to gain access to networks, it has used exploits for known vulnerabilities (N-days) in a large number of software products, operating systems, and libraries, including: SAP Solution Manager, Microsoft Open Management Infrastructure, Microsoft Exchange Server, Pivotal Spring Data Commons, Struts2, Eyou Email System, Beijing Grandview Century eHR Software, Weaver Ecology-OA, Commvault CommCell CVSearchService, Zhiyuan OA, Microsoft Windows, networking products from Ruijieyi Networks and D-Link, and more. “On one occasion, we observed the actor connecting to e-passport and e-visa services associated with a ministry of foreign affairs,” the researchers said. “Because the server for these services was configured with Atlassian Crowd software, the actor attempted to exploit CVE-2019-11580, uploading a payload named rce.jar.” A complex toolset of implants In addition to Cobalt Strike, the group uses various other malware payloads and command-and-control (C2) frameworks, including VShell, Havoc, SparkRat, and Sliver. On compromised web servers, the attackers deploy a variety of web shells, including Behinder, Neo-reGeorg, and Godzilla. On Linux servers the group has been seen deploying a rootkit dubbed ShadowGuard, which leverages the Extended Berkeley Packet Filter (eBPF), a powerful feature for running sandboxed code inside the Linux kernel. “eBPF backdoors are notoriously difficult to detect because they operate entirely within the highly trusted kernel space,” the researchers said. “eBPF programs do not appear as separate modules. Instead, they execute inside the kernel’s BPF virtual machine, making them inherently stealthy. This allows them to manipulate core system functions and audit logs before security tools or system monitoring applications can see the true data.” ShadowGuard appears to be a tool that’s unique to this group and allows them to hide processes, files, and directories. To conceal outgoing network traffic from victim networks, the attackers use a variety of relay and proxy servers running tunneling software like the GO Simple Tunnel (GOST), Fast Reverse Proxy Server (FRPS), and IOX, but their C2 servers are typically hosted on virtual private servers (VPS) from the US, UK, and Singapore. Increase in targeting Palo Alto believes the group is expanding its operations because it has scanned networks of organizations from 155 countries for known vulnerabilities since October. The scans appear to be targeted on IP addresses belonging to government infrastructure and specific targets of interest. For example, during the US government shutdown that began in October, the group started scanning the infrastructure of governments in the Americas, including in Brazil, Canada, Dominican Republic, Guatemala, Honduras, Jamaica, Mexico, Panama, and Trinidad and Tobago. The researchers believe the group has already compromised entities in Bolivia, Brazil, Mexico, Panama, and Venezuela. The group seems to time its targeting to certain events. For example, when the president of Czechia met with the Dalai Lama in August, the group immediately started scanning the computer infrastructure belonging to the Czech Army, police, parliament, and presidency, as well as its ministries of interior, finance, and foreign affairs. “TGR-STA-1030 remains an active threat to government and critical infrastructure worldwide,” Palo Alto said. “The group primarily targets government ministries and departments for espionage purposes. We assess that it prioritizes efforts against countries that have established or are exploring certain economic partnerships.” The company’s report includes indicators of compromise, including IP addresses, domain names, and file hashes for the implants used by the group. View the full article

Substack, a high-profile publishing platform widely used by academics, journalists, subject matter experts, and controversialists, has suffered a data breach affecting an unknown number of its creators and subscribers. According to emails sent out this week to some users, on February 3 the company “identified evidence” that a third party had exploited an unspecified weakness in the company’s systems to gain access to user email addresses, phone numbers and, more vaguely, “other internal metadata.” The breach happened in October 2025, which means that data, which the company said did not include credit card numbers, passwords, or financial information, has been exposed for up to four months. “We have fixed the problem with our system that allowed this to happen. We are conducting a full investigation, and are taking steps to improve our systems and processes to prevent this type of issue from happening in the future,” said the email from Substack CEO Chris Best. “We do not have evidence that this information is being misused, but we encourage you to take extra caution with any emails you receive that may be suspicious.” No passwords to lose At the time of publication, Substack had not yet made a web announcement about the breach, limiting itself to sending emails to users. This implies that the breach only affects a subset of its estimated 35 million active users. Indeed, the language of the email alert downplays the incident, describing the exposed data as merely being “shared without your permission.” However, the fact that the breach was only discovered this week, after a four-month delay, raises the possibility that its scope could yet grow as Substack conducts deeper forensics. A dark web source claimed the breach compromised 697,313 records, although this remains unconfirmed. It also reported that IDs from payment system Stripe, used by creators to receive payment from their subscribers, were compromised. Based on the wording of the email alert sent by the company, the breach only affects users who have Substack accounts; anyone who subscribes to a Substack creator’s newsletter directly using an email address shouldn’t be affected. The full extent of what was exposed is less clear. In addition to email addresses and phone numbers, the company mentioned “metadata,” a catch-all term. In its privacy policy, Substack describes a wide range of data this might include, depending on how the site is used, including user IDs, profile pictures, biographies, and IP addresses. How should Substack users react? Normally, the advice after any data breach is to change the account password. However, Substack’s default access method is via email address, with authentication confirmed by sending a “magic link” to the user’s email address. This removes the problem of password compromise and phishing attacks by not having a password to phish. If optional multi-factor authentication is turned on, the user must additionally enter a onetime code from an app. Passwords are still possible — users who signed up before 2023 might have one — but in 2026, the user must actively choose to create one. The company doesn’t mention whether this subset of users should consider changing their passwords as a precaution, but did offer the following statement: “We cannot share specifics about our security systems and processes, but we can confirm that the issue has been resolved and safeguards have been put in place to help prevent this issue from happening again.” Substack’s only other known security incident happened in 2020 when it accidentally exposed user email addresses by adding them to the “cc” (carbon copy) field instead of the “bcc” (blind carbon copy) of an email when sending out a policy update. View the full article

In a recent incident, attackers abused a legitimate but vulnerable Windows kernel driver to shut down endpoint security tools during an ongoing incident response. According to a Huntress report, the activity was observed during a customer investigation in early 2026 and involved the use of an old EnCase forensic driver (by Guidance Software) as part of the Bring Your Own Vulnerable Driver (BYOVD) technique to terminate Endpoint Detection and Response (EDR) processes from kernel mode. The intrusion began with compromised SonicWall SSL VPN credentials, after which the attacker conducted internal reconnaissance and deployed a custom “EDR killer” binary. “The attack was disrupted before ransomware deployment, but the case highlights a growing trend: threat actors weaponizing signed, legitimate drivers to blind endpoint security,” Huntress researchers said in a blog post. “The EnCase driver’s certificate expired in 2010 and was subsequently revoked, yet Windows still loads it, a gap in Driver Signature Enforcement that attackers continue to exploit.” Microsoft did not immediately respond to CSO’s request for comments. The BYOVD abuse According to the researchers, the attack used a common technique of abusing a legitimate signed driver that already has kernel-level privileges. This gave the attackers direct, high-privilege access to the kernel, effectively allowing them to terminate almost any process they want, including security tooling. Windows’ Driver Signature Enforcement, the policy requiring all kernel-mode drivers to be digitally signed by a trusted Certificate Authority (CA), doesn’t check certificate revocation lists at kernel load time. Researchers noted this to be a legacy behavior that remains exploitable because of backward compatibility features introduced years ago that allow an exception for drivers signed with certificates issued before July 29, 2015, that chain to a supported cross-signed CA. The EnCase driver contains a timestamp from a VeriSign service, which the authentication check still considers valid. “When code is signed with a timestamp, Windows validates the signature against the time the signature was created, not the current date,” the researchers noted. “Because the driver was timestamped while the certificate was still valid (before January 31, 2010), the signature remains valid indefinitely, even though the certificate has since expired.” Once in the kernel, the driver exposes an IOCTL interface that lets the malware terminate arbitrary processes with full system privileges. Among the functionality exposed are process termination commands that bypass user-mode safeguards for Protected Process Light (PPL) processes, the defenses EDR systems depend on to avoid tampering. The kill list excluded Huntress The EDR killer binary used in the Huntress-observed attack packed a 64-bit Windows executable and a custom encoded kernel driver payload, which it decoded into OemHwUpd.sys and installed as a kernel-mode service. Because Windows still honors its cryptographic signature, the attackers were able to load the driver. Once the vulnerable driver was in place, the EDR killer compiled an internal list of 59 well-known security tool processes, hashing their names and continuously checking for their presence on the system. “The kill loop runs continuously with a 1-second sleep interval, ensuring any security process that restarts is immediately terminated again,” the researchers said. Incidentally, Huntress said it wasn’t on the kill list. “While the EDR killer targets nearly every major EDR and AV vendor on the market, the Huntress agent was not among the 59 processes targeted for termination,” it added. Once the driver was written to disk, the binary established persistence by registering it as a Windows kernel service. Huntress recommended enabling Microsoft’s Vulnerable Driver Blocklist on all supported Windows systems to prevent known abused drivers from loading. The researchers also advised enforcing strong access controls on remote access services, including MFA for VPNs such as SonicWall, and closely monitoring for suspicious driver installation activity. Where possible, organizations are also encouraged to enable virtualization-based security features like Hypervisor-protected Code Integrity (HVCI) to further restrict kernel-mode abuse. View the full article

Buhlmann Group Akira zählt zu den gefährlichsten Ransomware-Gruppen und ist bekannt für zahlreiche Angriffe auf deutsche Unternehmen. Nun hat es offenbar den Bremer Stahlhändler Buhlmann getroffen. In einem Darknet-Post verkündet die Hackergruppe, sensible Informationen von der Buhlmann Group gestohlen zu haben. Die Angreifer drohen dem Unternehmen damit, 55 Gigabyte Daten zu veröffentlichen. Die Buhlmann Gruppe hat sich bisher noch nicht offiziell dazu geäußert. Gegenüber dem Regionalmagazin buten un binnen bestätigte eine Sprecherin, dass eine US-Tochterfirma von einem Cyberangriff betroffen sei. Das angegriffene IT-System werde jedoch nur in den USA genutzt. Standort in Deutschland nicht betroffen “Ein Zugriff auf IT-Systeme und Daten anderer Gesellschaften, insbesondere solcher in Deutschland und der EU ist nicht erfolgt und auch nicht möglich”, so die Unternehmenssprecherin. Daher seien auch keine Daten außerhalb vom Standort in den USA gefährdet. Nach eigenen Angaben beschäftigt die Buhlmann Group rund 2.000 Mitarbeitende in 23 Ländern. Das Unternehmen erzielte im Jahr 2024 einen Jahresumsatz von 428 Millionen Euro. Lesetipps: Akira greift Bäckereikette Schäfer an Akira attackiert Ideal Versicherung View the full article

Most security leaders believe they know where their sensitive data lives and how it is protected. That confidence is increasingly misplaced. As enterprises deploy AI across customer support, software development, legal analysis and internal operations, a new data exposure surface has quietly emerged. It does not sit in databases, file systems or network links. It lives inside AI inference traffic an area that falls outside most traditional security models and visibility frameworks, as InfoWorld explains in its analysis of why AI is all about inference now. This shift has happened quickly. In many organizations, AI systems have moved from pilot projects to core infrastructure in less than two years. Yet security architectures have not evolved at the same pace. The result is a widening gap between where sensitive data actually flows and where security teams are looking. This gap is rapidly becoming one of the most overlooked security risks in modern enterprise environments. AI prompts are high-value targets AI prompts are often dismissed as transient inputs temporary strings of text that exist only for the duration of a request. In reality, they frequently contain some of the most sensitive data an organization possesses: Proprietary source code and internal tooling Confidential documents and legal contracts Customer PII and financial records Strategic workflows and decision logic Recent industry analysis shows that enterprises are increasingly feeding sensitive proprietary data into generative AI systems to improve relevance and accuracy, particularly as organizations work to unlock internal data layers for AI-driven applications. InfoWorld has documented this trend in its discussion of getting the enterprise data layer unstuck for AI. From a business perspective, this makes sense. AI systems perform best when they are grounded in real organizational knowledge. From a security perspective, however, it represents a fundamental change in how sensitive data is handled. Information that was once confined to controlled repositories is now being copied, transformed and transmitted as part of inference requests. Unlike traditional data flows, prompts are rarely classified, sanitized or monitored. They pass through application layers, middleware, logging systems, observability pipelines and third-party services with minimal scrutiny. In many cases, they are treated as operational exhaust rather than as high-value data. This creates a dangerous mismatch: some of the most sensitive data in the organization is flowing through one of the least protected pipelines. Why existing controls fall short Traditional security architectures were not designed for AI workloads, and the limitations become clear at the inference layer. Encryption protects data only until it is decrypted for processing. At that point, prompts may be exposed to application memory, runtime environments, debugging tools, observability platforms and administrative access. While transport encryption remains essential, it does little to reduce exposure once data reaches the systems that actually perform inference. Data loss prevention tools also struggle in this context. Legacy DLP solutions were built around structured data, well-defined patterns and predictable storage locations. AI prompts are dynamic, unstructured and context dependent. As a result, DLP tools often lack the semantic understanding needed to determine whether a prompt contains sensitive material or whether its use is appropriate. These limitations are well documented in discussions around why legacy DLP approaches fall short in modern data security environments. Logging and observability introduce another layer of risk. To troubleshoot AI systems, teams often log prompts, responses and intermediate states. These logs are then shipped to centralized platforms, retained for long periods and accessed by broad groups of engineers. What begins as a debugging convenience can quickly become a repository of sensitive data stored far outside its original security perimeter. In many environments, trust effectively stops at the API gateway. Beyond that boundary, AI inference traffic is implicitly trusted, even though it frequently crosses internal and external trust zones. This implicit trust model may have worked for traditional application architectures, but it is poorly suited to AI systems that blur the line between user input, internal data and external services. Internal risk is the bigger threat While external attackers remain a concern, internal exposure is often the more likely and less visible risk. Over-permissioned service accounts, misconfigured logging pipelines, compromised credentials or legitimate insider access can all result in silent prompt leakage. Unlike traditional breaches, these exposures do not require exploitation of vulnerabilities. They occur as a byproduct of normal operations in complex environments. AI systems exacerbate this risk because of their scale and frequency of use. A single application may generate thousands or millions of inference requests per day, each potentially containing sensitive data. Within that volume, misuse or accidental exposure can easily blend into normal traffic patterns. Research into insider risk consistently shows that accidental exposure is far more common than malicious breach, particularly in cloud environments where ownership and responsibility are distributed across teams. AI systems add yet another layer of complexity, making it harder to answer basic questions about who can access inference data, where it is stored and how long it is retained. Because AI usage is frequent and expected, abnormal access patterns may not trigger alarms. This makes AI inference an ideal low noise channel for data exposure one that does not resemble traditional indicators of compromise and is therefore difficult to detect with existing tools. The quantum time bomb Beyond immediate exposure, there is a longer term risk that security leaders can no longer afford to treat as theoretical: cryptographic durability. AI prompts and responses often contain data that must remain confidential for many years source code that underpins competitive advantage, customer records subject to regulatory protection, proprietary processes and strategic decisions. Yet much of today’s AI inference traffic is protected using cryptographic methods designed primarily for short-term transport security, not long term confidentiality. This distinction matters. Advances in quantum computing threaten to weaken many of the cryptographic algorithms currently used to protect data in transit and at rest. While large-scale, fault-tolerant quantum computers are not yet widely available, the associated risk is already present. Adversaries can capture encrypted data today and decrypt it later, once cryptographic assumptions fail. Security agencies and standards bodies have explicitly warned about these “harvest now, decrypt later” threats. The National Institute of Standards and Technology has highlighted the need to assess which data assets require long-term protection in its post-quantum cryptography guidance. AI significantly expands the volume of data that may fall into this category. Inference traffic often includes rich contextual information that would be highly valuable if decrypted in the future. Unlike traditional records, this data is frequently generated at scale and retained in logs, analytics systems or backups without clear lifecycle controls. For regulated industries with long data-retention requirements such as finance, healthcare and critical infrastructure this creates a silent exposure window that extends far beyond current compliance cycles. Organizations may be meeting today’s regulatory requirements while unintentionally accumulating long-term cryptographic risk. AI has unintentionally expanded not just the amount of sensitive data in motion, but the amount of data that must remain secure well into a post-quantum future often without organizations realizing it. The bottom line for security leaders This gap exists not because teams are careless, but because AI inference does not fit cleanly into existing security models. It crosses trust boundaries that were never designed with AI in mind and introduces data flows that traditional controls were never built to govern. As AI becomes embedded in core enterprise workflows, the security implications of inference traffic can no longer be treated as an edge case. They represent a fundamental shift in how sensitive data is created, processed and exposed. This is not a call for a specific solution, but a problem the industry can no longer afford to ignore. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Microsoft has developed a scanner designed to detect backdoors in open-weight AI models, addressing a critical blind spot for enterprises increasingly dependent on third-party LLMs. In a blog post, the company said its research focused on identifying hidden triggers and malicious behaviors embedded during the training or fine-tuning of language models, which can remain dormant until activated by specific inputs. Such backdoors can allow attackers to alter model behavior in subtle ways that enable data exposure or allow malicious activity to slip past traditional security controls unnoticed. As enterprises increasingly rely on third-party and open-source models for applications ranging from customer support to security operations, the integrity of those models is under scrutiny. “Unlike traditional software, where scanners look for coding mistakes or known vulnerabilities, AI risks can include hidden behavior planted inside a model,” said Sunil Varkey, a cybersecurity analyst. “A model may work normally but respond in harmful ways when it sees a secret trigger.” That risk is more concerning because LLMs can be deployed without deep inspection, leaving security teams with limited visibility into their training or vulnerabilities. Signatures that suggest backdoors Microsoft’s researchers identified three observable indicators, or “signatures,” that suggest the presence of backdoors in language models. One of the strongest indicators is a shift in how a model pays attention to a prompt when a hidden trigger is present. In backdoored models, trigger tokens tend to dominate the model’s attention, effectively overriding the rest of the input. “We find that trigger tokens tend to ‘hijack’ the attention of backdoored models, creating a distinctive double triangle pattern,” Microsoft said. The researchers also found that backdoored models may leak information about how they were poisoned. In some cases, specific prompts caused models to regurgitate fragments of the very training data used to insert the backdoor, including parts of the trigger itself. Another key finding is that language model backdoors behave differently from traditional software backdoors. Rather than responding only to an exact trigger string, many backdoored models react to partial or approximate versions of the trigger. Effectiveness of the scanner Microsoft said the scanner does not require retraining models or prior knowledge of backdoor behavior and operates using forward passes only, avoiding gradient calculations or backpropagation to keep computing costs low. The company also said it works with most causal, GPT-style language models and can be used across a wide range of deployments. Analysts say that while the approach improves visibility into language model poisoning, it is an incremental advance rather than a breakthrough, noting that several leading EDR platforms already claim the ability to detect backdoors in open-weight LLMs. The bigger question is how long such detection advantages will last. “While this new scanner will help counter real-world attacker techniques currently, adversaries will adapt quickly to outflank this scanner,” said Keith Prabhu, founder and CEO of Confidis. “We are seeing a repeat of the ‘virus’ wars, where hackers kept evolving viruses to evade detection by using innovative techniques like polymorphic viruses.” That said, the scanner is essential for companies that download open-source models to use or customize in their own systems, according to Varkey. “For them, AI models become part of the supply chain, just like software libraries,” Varkey said. “The scanner is not a complete solution, but it is an important new layer of protection as AI adoption grows.” View the full article

Cybersecurity is a boardroom issue, but meaningful dialogue often breaks down at the table. Boards ask about cybersecurity investments and cyber resilience; they need answers rooted in reality, not prognostication. When cybersecurity leaders respond with a list of technologies deployed and potential risks that require additional investment, board members may get frustrated by a lack of clear answers and lose trust. This is a great opportunity for CISOs to take a different approach. Part of the challenge is that most boards don’t have cybersecurity practitioners and expertise, making it challenging to understand the linkage between technical risks and business impact. It’s the responsibility of the CISO to translate technical cybersecurity outcomes into business terms that enable board members to make well-informed decisions on future investments and financial protection for the business. Additionally, senior leadership teams need to be prepared to discuss concepts like risk appetite and potential degrees of business interruption. That’s because no amount of cybersecurity investment can guarantee zero disruptions; a certain amount of risk must be accepted. Unfortunately, this unintentional communication gap comes with the nature of cyber threats. The board wants to know how well-positioned the company is to avoid costly business interruptions, regulatory penalties or class action lawsuits from cyber incidents. It’s tempting to rely on internal audits and regulatory compliance (such as SOC2 attestations), but these don’t provide a robust answer to cyber resilience: many companies have failed to stop cyberattacks despite extensive investments in cybersecurity tools and compliance. (In fact, Gartner predicts worldwide end-user spending on information security will reach $240 billion in 2026) Cybersecurity leaders desperately need to prove the performance of cybersecurity investments and demonstrate confidently and with evidence that safeguards are working as intended all the time. There’s an obvious opportunity to change the conversation with boards and senior leadership teams. Why trust fails: The limits of compliance and communication Cybersecurity frameworks like NIST and CSF — and complying with these frameworks — are key. However, while they were designed to standardize and validate an acceptable level of controls, they don’t guarantee positive cybersecurity outcomes. Passing an audit once a year doesn’t mean your controls work every day. For instance, a misconfigured control can create direct breach exposure. A backup gap might break your recovery time objective (RTO) promise. A missing insurance requirement at the time of an attack could void coverage. It’s tempting for CISOs to present heatmaps and dashboards that are too technical for board members. When executives ask why something is red, the conversation may wander into what seems to the board like subjectivity. The Securities and Exchange Commission (SEC) cybersecurity disclosure requirements have forced boards to engage. New rules have increased visibility and consequences for both boards and CISOs without necessarily improving fluency. CISOs are accountable but still lack the means to prove the outcome of their team’s work. Bridging the language gap between cybersecurity leaders and business requires translation, but it’s also an opportunity to redefine the role of cybersecurity and focus on the desired outcome sought after by business leaders: cyber resilience. Building a common language to get to “Here’s the proof of cyber resilience” CISOs can reframe the discussion using data and evidence. Modern cybersecurity tools produce a large volume of data and information on how they operate at any point in time, the status of controls deployed, the validation of configuration and more. There’s an opportunity to collect such data, sanitize it and derive continuous insights that validate, at any point in time, not just compliance with cybersecurity regulations but also overall cybersecurity posture. Because these insights are proof of actual state, the CISO can illuminate gaps in protection on an ongoing basis and either address these gaps or help the business determine mitigation priorities. And in some cases, a perfectly appropriate business decision is to accept a risk. It’s important to capture that acceptance formally, document why it was accepted and ensure that the acceptance is reviewed on an appropriate cadence so the level of risk over time doesn’t outpace a company’s appetite. This will remove subjectivity and confusion from board reports. CISOs can show proof of readiness and effectiveness, and boards can interpret results in familiar business terms. Practical steps for CISOs to prove resilience Cybersecurity deployment is critical, but insufficient. Every day, even organizations with robust cybersecurity investments fall victim to cyber attacks. Board and business leaders put the burden on cybersecurity leaders, but actually demand more: they want cyber resilience. Cyber resilience is the ability to continue critical operations under degraded circumstances, like a cyber incident, and the agility to return to normal operations quickly and with minimal financial impact. It’s more than the deployment of cybersecurity tools. Backups must be recoverable, and cyber insurance policies need to pay claims. Ideally, the organization knows how long it takes to restart systems from backup and has all information at hand for claims to be paid fully and quickly. Today, no single role owns cyber resilience, but different aspects are the purview of the CISO (safeguards), the CIO (backups) and the CFO (insurance). Collaboration between all three is required to assess that all safeguards are in place. It’s also time to upgrade manual tracking of safeguards to evidence-based, automated tracking. The next step is to shift from activity reporting to evidence sharing and decision support. This includes providing a clear view of the state of cybersecurity, which then surfaces risks that the business needs to make decisions on in terms of whether to mitigate or accept. To use evidence to demonstrate whether the business is meeting its goals for cyber resilience, data must replace prediction. Next, automate low-value work. Free teams from repetitive audit preparation by using tools to aggregate and provide tamper-proof evidence. Focus human expertise on strategy and decision-making for cyber resilience instead of administrative tasks. Finally, educate and contextualize for the board. Deliver short, outcome-focused updates that tie cybersecurity performance to cyber resilience goals. Reinforce the point that business risk and continuity ultimately reside with the board, not the CISO. Better language, stronger trust Cyber resilience is a business problem, not an IT and cybersecurity problem. The board will understand it when evidence-driven communication fosters transparency, trust and clarity of action. As they hear information relayed in language they can understand, boards gain confidence in investments and governance decisions. This results in fewer redlines on board reports, more meaningful conversations and longer CISO tenures. It moves cybersecurity from a reactive cost center to a proactive value driver. When CISOs can show proof tailored to the company’s own risk tolerance, the conversation changes from uncertainty to clarity. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

FamVeld – shutterstock.com Wenige Tage vor Beginn der Olympischen Winterspiele in Mailand und Cortina d’Ampezzo hat Italien mehrere russische Hackerattacken abgewehrt. Die Cyberangriffe hätten unter anderem einige Standorte der Winterspiele, darunter Hotels in Cortina, zum Ziel gehabt, sagte Außenminister Antonio Tajani. Auch Einrichtungen seines Ministeriums seien betroffen gewesen. Tajani betonte während eines Besuchs in Washington, die Angriffe seien russischen Ursprungs gewesen. Er bedankte sich bei den Sicherheitsbehörden, die diese vereiteln konnten. “Die Cybersicherheit wird zu einem zentralen Faktor, daher bin ich sehr zufrieden. Selbstverständlich haben wir alle anderen zuständigen Behörden informiert”, sagte der Minister weiter. Wie italienische Medien berichteten, haben sich die lokalen Behörden auf die Risiken durch Cyberattacken während der Winterspiele frühzeitig vorbereitet. Ein Team aus Fachleuten arbeitet demnach gemeinsam mit Experten der Organisatoren der Spiele daran, Angriffe auf das Großevent abzuwehren. Die Winterspiele beginnen am Freitag und dauern bis zum 22. Februar. (dpa/jm) View the full article

Software supply chain failures and mishandling of exceptional conditions are some of the additions to the updated OWASP Top 10, a list of top web application vulnerabilities. Most of the list has remained unchanged since 2021. In fact, the top item, broken access control, has been on the Open Worldwide Application Security Project’s list since it was first released in 2003. “Everyone tries to craft their own authentication and access control mechanisms,” says Jeff Williams, CTO and cofounder at Contrast Security. Williams created the list and served as the chair of the OWASP board for eight years. There are standard mechanisms out there, but most applications have specialized needs, he says. “I’ve seen some really god-awful horrific machines that people have built to do access control checks, and they don’t build them elegantly. They build them piece by piece. ‘Oh, we’re building this function, we need to do an access check’ — and they build their own access check. And almost nobody tests access control.” A typical web application may have a hundred endpoints, Williams says, each one of which can be accessed by a number of different roles. “Now you have to make sure that each of those routes work in each of those roles. Most people do a scan of their application with one role in mind, like that of a normal user. And maybe with an admin user. But there could be twenty different roles, so it’s very difficult to verify.” AI didn’t make the top ten list, but it was included in a “next steps” section of issues on the cusp of inclusion, in addition to a lack of application resilience and memory management failures. This AI category is titled: X03:2025 Inappropriate Trust in AI Generated Code (‘Vibe Coding’). “Although we didn’t have data to support the fact that AI-generated code is causing significantly more risk than human-written code available, thanks to community feedback, professional experience, and constant online sharing of such data, we felt it prudent to add a section,” says Tanya Janca, lead author of the OWASP Top 10. Developers should read and fully understand AI-generated code before committing it, she says. The OWASP Top 10 list is based on a combination of security data from a dozen different organizations, covering nearly 3 million applications, as well as a survey of 221 security experts, says security metrics expert Aram Hovsepyan, CEO at Codific and an OWASP contributing member. Here are the top 10: 1 – Broken access control When applications fail to properly enforce restrictions on what authenticated users are allowed to do, allowing attackers to access unauthorized functionality or data. For example, an attacker might manipulate an URL parameter to access another user’s account information or escalate their privileges from a regular user to an administrator. This item now includes server-side request forgery, which was its own list item in 2021. 2 – Security misconfiguration Security settings are not properly defined, implemented, or maintained, leaving systems exposed to attack. Common examples include default credentials that are never changed, unnecessary features left enabled, verbose error messages that reveal sensitive information, or cloud storage buckets left publicly accessible. This vulnerability jumped from fifth place in 2021 to second place in 2025. 3 – Software supply chain failures Attackers compromise software during the build, distribution or updates to inject malicious code that gets distributed to multiple organizations. For example, attackers might compromise a popular open-source library and inject malicious code that then gets incorporated into thousands of applications that depend on it or breach a vendor’s system to insert backdoors into legitimate software updates. This is a new list item, though there was a narrower related item in 2021 — vulnerable and outdated components. “Developers have become a primary target for many online attacks now,” says Janca. “It is no longer a problem of including a library that has a questionable dependency.” Instead, she says, there are now active attacks against the IDE, against the CI/CD pipeline, against plugins and repositories, against developer workstations, and more. “The entire software supply chain is currently a focus for attackers,” she says. 4 – Cryptographic failures Applications fail to properly protect sensitive data through encryption or use weak or broken cryptographic algorithms. Examples include transmitting sensitive data in clear text, using weak encryption algorithms, not properly validating SSL/TLS certificates, or storing passwords without proper hashing. These failures often lead to sensitive data exposure or system compromise. This item moved down from second place on 2021’s list. 5 – Injection Untrusted data is submitted as part of a command or query, tricking the application into executing unintended commands or accessing unauthorized data. Examples range from cross-site scripting, where attackers inject malicious scripts into web pages viewed by other users, to SQL injection, where they use database queries to access or modify sensitive data. This item has also moved a couple of spots down on this year’s list. 6 – Insecure design Security wasn’t properly considered during the design phase of the application, resulting in missing or ineffective controls. Examples include failing to implement proper threat modeling, not establishing security requirements before development begins, or designing systems that lack defense in depth. This category was introduced in 2021 to focus on design and architectural flaws rather than implementation bugs, but it’s moved down a couple of places because the industry has made noticeable improvements in threat modeling. 7 – Authentication failures Applications fail to properly verify the identity of users or fail to protect authentication credentials and session tokens. Examples include allowing brute force attacks, permitting weak passwords, exposing session IDs in URLs, not properly invalidating sessions after logout, or failing to implement multi-factor authentication for sensitive functions. 8 – Software or data integrity failures Applications fail to maintain trust boundaries and verify the integrity of software, code, and data artifacts. Examples include applications that rely on plugins, libraries, or modules from untrusted sources without integrity checks, insecure CI/CD pipelines that allow code to be modified before deployment, or applications that auto-update without verifying digital signatures. 9 – Security logging and alerting failures Applications fail to log security-relevant events or fail to alert security teams when suspicious activities occur. Examples include not logging failed login attempts, storing logs locally without backup, logging insufficient detail to reconstruct attacks or generating logs that don’t integrate with security information and event management (SIEM) systems. Great logging with no alerting is of minimal value in identifying security incidents. 10 – Mishandling of exceptional conditions Applications fail to properly handle errors, edge cases, and abnormal conditions, leading to security vulnerabilities. Examples include displaying detailed error messages that reveal sensitive information about system architecture, security checks that fail and allow unauthorized access when errors occur, or applications that crash and expose sensitive data in memory dumps. This is a category that has been just outside the top 10 for several years, says Brian Glas, department chair of computer science at Union University and an OWASP project leader. What took this item over the top was not the data about existing vulnerabilities, he says, but the survey of experts. “If it was purely data-driven, we would not have an accurate list as it would only be looking into the past.” Related stories: 10 most critical LLM vulnerabilities Managing agentic AI risk: Lessons from the OWASP Top 10 Understanding OWASP’s Top 10 list of non-human identity critical risks Keeping up with AI: OWASP LLM AI Cybersecurity and Governance Checklist View the full article

A study released Wednesday by API management platform vendor Gravitee indicates that upwards of half of the three million agents currently in use by organizations in the US and UK “are ungoverned and at the risk of going rogue.” Based on a December 2025 survey of 750 IT executives and practitioners conducted by Opinion Matters, the results revealed that AI agents are being deployed faster than security teams can keep up. There are, said Rory Blundell, CEO of Gravitee, now over three million AI agents operating within corporations, which he described as a workforce larger than the entire global employee count at Walmart. The three million number is based on an extrapolation of survey results, based on government estimates of 8,250 UK businesses and 77,000 US businesses that employ 250 employees or more. The mean number of AI agents deployed per business is 36.9, and when respondents were asked if their organization “experienced or suspected an AI agent-related security or data privacy incident in the past 12 months,” 88% said that they had. The mean percentage of agents that are not actively monitored and secured, according to the findings, was 53% Asked what prompted the study, Blundell wrote in an email, “we’re all familiar with stories of AI agents going rogue: deleting codebases, leaking confidential information, inventing fake data. The working hypothesis that prompted this research was that, while agentic deployment is reaching an exciting stage, businesses have not yet caught up with agent governance. The research validates that.” A global problem Agents, he said, “can offer businesses a huge productivity gain, but we have to be realistic about the risks: without governance and oversight, they can easily start becoming liabilities, and a danger to consumers and businesses alike.” In addition, said Blundell, despite respondents being only from the UK and US, “this is absolutely a global problem. Companies around the world are using AI agents, and across the board there is a gap between the level of deployment and the level of governance. We have a strong customer base in the EU, where we see the same problems.” David Shipley, head of Canadian-based security awareness training firm Beauceron Security, said, “the only thing that shocks me is that people think it’s only 53% of agents that aren’t monitored. It’s higher.” He likened the results from the Gravitee study to a “lesson about the Titanic that everyone in technology keeps ignoring. The Titanic disaster didn’t happen because they didn’t know there would be icebergs on the trip. They knew it was peak iceberg season, they knew they were going too fast.” Shipley said that the ship’s captain and his crew “thought they’d detect [an iceberg]; if they didn’t, and hit one, that their technology controls would protect them to help them recover.” They put their faith in the so-called watertight compartments that, it turned out, weren’t watertight at the top, but, most importantly, they trusted the new wireless communications technology that they could use to call for help if they got in trouble. The equivalent today: “Well, IT and security can fix it if we get in trouble with our agents.” “Wrong then, super wrong now,” he said. He said, “we know AI agents are inherently dangerous and unreliable. There’s literally math proofs out there that show it. So, we know there are icebergs. Let me repeat this for those at the back of the room: 100% of AI agents have the potential to go rogue. If a vendor assures you it isn’t possible and their core technology is an LLM, they’re lying. We know we’re going too fast in adoption for the risks we know exist.” Shipley added, “now, the funny part: imagine if the Titanic still made the choices it did, knowing the watertight compartments didn’t work (aka monitoring is missing for 53% of AI agents), we know by the time IT and security roll on an AI agent risk, the damage is done (the ship’s sinking too fast and radio isn’t going to help because help will be too late). And we still made the choices we’re making.” The real issue is invisible AI, not rogue AI Manish Jain, principal research director at Info-Tech Research Group, said that as the “exponential” speed of AI development continues, his firm, based on experiences with CIOs and CDOs, predicts that there will be more AI agents globally by the year 2028 than the number of human employees. “It would be one of the biggest challenges for business and IT executives to govern them without curtailing the innovation that these AI agents bring with them,” he said. Even today, he noted, “we see that most enterprise AI agents are running without oversight. Many organizations don’t even know how many agents they have, where they’re running, or what they can touch. If you don’t know how many mules are in the barn, don’t act surprised when one kicks the door down.” Jain pointed out that AI agents are no different. “Unaccounted agents often emerge through sanctioned, low-code tools and informal experimentation, bypassing traditional IT scrutiny until something breaks. You cannot govern what you can’t see. So, we need to understand that the real issue isn’t ‘rogue AI’, it’s invisible AI.” Info-Tech, he added, “strongly believes that governing AI models or pre-approving agents is no longer enough, because invisible, rogue agents will do tandava (the dance of destruction) at runtime. This is because, when it comes to governing these AI agents, the number is so huge that approval gates will not be sustainable without halting the innovation. Continuous oversight should be the priority for AI governance after setting initial guardrails as part of the AI strategy.” Perspective, he said, also needs to change: “AI agents are no longer helpful bots. They often operate with delegated yet broad credentials, persistent access, and undefined accountability. This can become a costly mistake as overprivileged agents are the new insider threat. We need to define tiered access for AI agents. While we can’t avoid giving a few people keys to our house to speed up things, if you trust every stranger with your house keys, we wouldn’t be able to blame the locksmith when things go missing.” View the full article

Threat actors exploiting the React2Shell vulnerability in components of React servers are using their access to compromise web domains and divert web traffic for malicious purposes. That’s the conclusion of researchers at Datadog Security Labs, who said in a blog Wednesday that the primary targets are sites running the NGINX open-source web server managed with Boato Panel. These include Asian organizations with top level domains ending in .in, .id, .pe, .bd, .edu, .gov, and .th, as well as Chinese hosting infrastructure. The danger, said blog author Ryan Simon, a senior security researcher at Datadog Security Labs, is that a hacker can use a compromised site to do a number of nasty things such as fingerprint an organization’s web traffic, insert malware onto users’ computers, or divert traffic to a threat actor-controlled landing page that tries to trick users into giving up login credentials. These last two tactics also end up damaging a website’s reputation, Simon added, if the word gets around that the site hosts malware. NGINX is a “foundational element of contemporary web infrastructure,” the Datadog blog notes. The routing and processing of traffic by NGINX is governed by its configuration files. Poor configuration or a successful breach allow it to be used for web traffic hijacking. For CSOs, the defense against these attacks is to lock down those configuration files to resist their being tampered with. React2Shell is the exploitation of a vulnerability (CVE-2025-55182) in the React 19 library for building application interfaces that was discovered late last year. The hole allows attackers to execute arbitrary code on affected servers. Related content: Anatomy of React2Shell Researchers at Greynoise said this week that exploitation activity targeting React Server Components has consolidated significantly. Two IP addresses now account for 56% of all observed exploitation attempts, down from 1,083 unique sources earlier. Unpatched versions of React are at risk of compromise. Initial abuse “What we saw in a lot of our honeypots and threat intelligence early on with React2Shell is attackers were using it for cryptomining,” said Simon. Others have seen exploitation used to deploy reverse shells. But more recently, Simon said, Datadog Security is seeing threat actors, once in an IT network, going after web servers to highjack their traffic. An analysis of the scripts used by threat actors on compromised NGINX web servers shows they use a multi-stage and automated approach to attacking the environments. The toolkits contain target discovery plus several scripts designed to establish persistence and for the creation of malicious configuration files containing instructions intended to redirect web traffic, says the Datadog blog. There is no commonality among the targeted organizations, Simon noted. Hijacking web traffic is an old tactic for threat actors. In fact David Shipley, head of Canadian security awareness training provider Beauceron Security, called these attacks on NGINX servers “a return to old-school hacking in the era of stronger identity controls like password managers, MFA and passkeys.” “If you’re up against a more robustly defended user, you go back to attacking the infrastructure so you can go back into attacker-in-the-middle mode for some good old session cookie capture and other hijinks on the NGINX,” he said. Finding and exploiting server side vulnerabilities or network security vulnerabilities is fast, cheap, and easy with AI, he added. Simon said CSOs can help protect NGINX servers from being exploited by monitoring configuration file integrity, including keeping records of their server configurations so any changes can be spotted. It’s vital that web servers have the latest security patches, he added. And admins should also monitor the NGINX security advisory website. View the full article

Threat actors exploiting the React2Shell vulnerability in components of React servers are using their access to compromise web domains and divert web traffic for malicious purposes. That’s the conclusion of researchers at Datadog Security Labs, who said in a blog Wednesday that the primary targets are sites running the NGINX open-source web server managed with Boato Panel. These include Asian organizations with top level domains ending in .in, .id, .pe, .bd, .edu, .gov, and .th, as well as Chinese hosting infrastructure. The danger, said blog author Ryan Simon, a senior security researcher at Datadog Security Labs, is that a hacker can use a compromised site to do a number of nasty things such as fingerprint an organization’s web traffic, insert malware onto users’ computers, or divert traffic to a threat actor-controlled landing page that tries to trick users into giving up login credentials. These last two tactics also end up damaging a website’s reputation, Simon added, if the word gets around that the site hosts malware. NGINX is a “foundational element of contemporary web infrastructure,” the Datadog blog notes. The routing and processing of traffic by NGINX is governed by its configuration files. Poor configuration or a successful breach allow it to be used for web traffic hijacking. For CSOs, the defense against these attacks is to lock down those configuration files to resist their being tampered with. React2Shell is the exploitation of a vulnerability (CVE-2025-55182) in the React 19 library for building application interfaces that was discovered late last year. The hole allows attackers to execute arbitrary code on affected servers. Related content: Anatomy of React2Shell Researchers at Greynoise said this week that exploitation activity targeting React Server Components has consolidated significantly. Two IP addresses now account for 56% of all observed exploitation attempts, down from 1,083 unique sources earlier. Unpatched versions of React are at risk of compromise. Initial abuse “What we saw in a lot of our honeypots and threat intelligence early on with React2Shell is attackers were using it for cryptomining,” said Simon. Others have seen exploitation used to deploy reverse shells. But more recently, Simon said, Datadog Security is seeing threat actors, once in an IT network, going after web servers to highjack their traffic. An analysis of the scripts used by threat actors on compromised NGINX web servers shows they use a multi-stage and automated approach to attacking the environments. The toolkits contain target discovery plus several scripts designed to establish persistence and for the creation of malicious configuration files containing instructions intended to redirect web traffic, says the Datadog blog. There is no commonality among the targeted organizations, Simon noted. Hijacking web traffic is an old tactic for threat actors. In fact David Shipley, head of Canadian security awareness training provider Beauceron Security, called these attacks on NGINX servers “a return to old-school hacking in the era of stronger identity controls like password managers, MFA and passkeys.” “If you’re up against a more robustly defended user, you go back to attacking the infrastructure so you can go back into attacker-in-the-middle mode for some good old session cookie capture and other hijinks on the NGINX,” he said. Finding and exploiting server side vulnerabilities or network security vulnerabilities is fast, cheap, and easy with AI, he added. Simon said CSOs can help protect NGINX servers from being exploited by monitoring configuration file integrity, including keeping records of their server configurations so any changes can be spotted. It’s vital that web servers have the latest security patches, he added. And admins should also monitor the NGINX security advisory website. View the full article

Russia-linked attackers are reportedly using a new Microsoft vulnerability as part of a coordinated espionage and malware campaign, Operation Neusploit. The campaign was spotted in January 2026 by Security researchers at ZScaler ThreatLabz, three days after Microsoft issued an urgent patch for the flaw. “In this campaign, the threat actor leveraged specially crafted Microsoft RTF files to exploit CVE-2026-21509 and deliver malicious backdoors in a multi-stage infection chain,” the researchers said in a blog post. “ThreatLabz observed active in-the-wild exploitation on January 29, 2026.” The campaign targeted users in parts of Central and Eastern Europe, including Ukraine, Slovakia, and Romania, with custom social engineering lures. The crafted rich text format (RTF) files triggered the Office vulnerability the moment they were opened, initiating a multi-stage infection chain leading to backdoors and malware implants. Owing to the significant overlap between the tools, techniques, and procedures (TTPs) between the campaign and those of Russia’s General Staff Main Intelligence Directorate (GRU)-affiliated threat group APT28 (aka Fancy Bear), ZScaler attributed the campaign to the advanced persistent threat (APT) group. Neusploit hooked users through Office Operation Neusploit relies heavily on CVE-2026-21509, a high-severity bug in Microsoft Office that Microsoft patched on January 26 after reports of active exploitation. The infection begins with victims receiving an email with an RTF attachment that contains a weaponized exploit. When opened, the RTF file causes Microsoft Office to execute code that reaches out to threat actor infrastructure and downloads a dropper DLL. The DLL then executes the rest of the malicious chain. “The threat actor employed server-side evasion techniques, responding with the malicious DLL only when requests originated from the targeted geographic region and included the correct User-Agent HTTP header,” the researchers said. The campaign used two different variants of the dropper DLL, deploying different components for different purposes. One campaign, two infection paths ZScaler found that exploitation of CVE-2026-21509 did not lead to a single uniform payload. Instead, the initial RTF-based exploit branched into two distinct infection paths, each serving a different operational purpose. The choice of dropper reportedly determined whether the attackers prioritized near-term intelligence collection or longer-term access to compromised systems. In one path, the exploit delivered MiniDoor, a lightweight DLL that focused on email theft. The malware modified Windows registry settings to weaken Microsoft Outlook security controls, allowing it to quietly collect and exfiltrate email data to an attacker-controlled infrastructure. The design and functionality of MiniDoor closely resemble earlier APT28 tooling, aligning with the group’s established espionage-focused attacks. The second path involved a more elaborate chain that began with PixyNetLoader, which deployed additional payloads and established persistence using techniques such as DLL proxying and COM object hijacking. This loader ultimately installed a Covenant Grunt implant, used specifically in .NET command and control (c2) framework, giving the attackers sustained remote access through cloud-hosted C2 infrastructure. Mitigation efforts ZScaler recommended that organizations prioritize patching for CVE-2026-21509, noting that APT28 exploited the flaw within days of Microsoft releasing fixes. Systems running unpatched versions of Microsoft Office remain exposed to weaponized RTF documents that require little user interaction beyond opening the file, significantly raising the risk of compromise in email-driven attack scenarios. For defensive analysis, ZScaler shared GitHub repositories, including the Windows scheduled task configuration file and the MiniDoor macro code, illustrating the attack paths used in Operation Neusploit. Additionally, the disclosure shared a list of indicators of compromise (IOCs) to support detection efforts, which included file hashes, malicious domains, and URLs. CISA had added the flaw to its known exploited vulnerabilities (KEV) database, giving Federal Civilian Executive Branch (FCEB) agencies until February 16 to patch their systems. View the full article

Romina Mineralbrunnen GmbH Der Getränke-Abfüller Romina mit Sitz in Reutlingen-Rommelsbach wurde kürzlich von einer Cyberattacke getroffen. Wie das Unternehmen auf seiner Website erklärt, sei man deshalb weder telefonisch noch per E-Mail erreichbar. Laut einem Bericht des Reutlinger General-Anzeiger steht auch die Produktion aktuell still. Weitere Details zu dem Vorfall gibt es bisher nicht. Daher ist unklar, wie der Angriff genau abgelaufen ist. Ebenfalls ist nicht bekannt, ob Daten gestohlen wurden. Der Regionalzeitung Südwest Presse zufolge ermittelt die Polizei Reutlingen bereits in dem Fall. Romina Mineralbrunnen beschäftigt nach eigenen Angaben 130 Mitarbeiterinnen und Mitarbeiter. 2024 hatte das Unternehmen 180,7 Millionen Füllungen verzeichnet und einen Umsatz von mehr als 40 Millionen Euro erwirtschaftet. View the full article

Over the past three years, I’ve led passwordless migration initiatives at three Fortune 500 companies, and I can tell you with confidence that eliminating passwords from a hybrid Active Directory and Microsoft Entra ID environment is one of the most rewarding — and most underestimated — technical challenges in modern identity management. The theoretical appeal is obvious: no passwords means no credential compromise, phishing becomes exponentially harder and your security posture fundamentally shifts from “prevent breaches” to “assume breach.” But the reality of implementation in environments spanning on-premises and cloud infrastructure? That’s where the genuine complexity lives. Most organizations I’ve worked with start this journey with romantic notions of flipping a switch and sailing into a passwordless future. What they discover instead is that achieving true passwordless authentication requires rethinking identity architecture from the ground up. It’s not about swapping one authentication method for another — it’s about fundamentally restructuring how you verify identity across every layer of your infrastructure. The transition demands careful planning, technical rigor and unwavering commitment to security principles over convenience. Prerequisites: Building the foundation before the migration Before we can talk about passwordless authentication, we need to address what I call the “prerequisite triangle”: cloud Kerberos trust, device registration and Conditional Access policies. Skip any one of these, and your migration will stall before it gains momentum. Cloud Kerberos trust is the unsung hero of hybrid passwordless deployments. When I started working on my first full migration, I underestimated how critical this piece was. Traditional Kerberos assumes a managed network with domain controllers you control. Cloud Kerberos allows your cloud-based services to issue Kerberos tickets to hybrid-joined devices without requiring a domain controller on the internet. This is your bridge between on-premises and cloud identity, and it’s non-negotiable for seamless hybrid authentication. The mechanics of Kerberos itself haven’t changed significantly since its introduction in the 1980s, but extending it to cloud environments required a fundamental rethinking of how authentication tickets are issued and validated across trust boundaries. Getting cloud Kerberos working requires Azure AD Connect to run version 2.0 or later with the cloud sync agent configured for password hash synchronization (even if you’re not using it for authentication — this remains a prerequisite). Your hybrid-joined devices need to be running Windows 10 20H2 or later, and they must have reliable network connectivity to both your on-premises domain controllers and Azure. In one deployment, my team spent two weeks troubleshooting authentication failures before discovering that a firewall rule was blocking the necessary communication on port 88. This single finding reinforced why network validation should occur before pilot rollout, not during. Device registration and management come next. Every device attempting passwordless authentication must be either Azure AD joined, hybrid AD joined or registered with Entra ID. I’ve found that hybrid-joined devices work best in truly hybrid environments because they maintain connection to on-premises infrastructure while gaining cloud identity benefits. Your Intune Mobile Device Management deployment becomes critical here — devices must be compliant with your policies before they’re trusted for passwordless sign-in. This means ensuring that disk encryption is enabled, that antivirus is running and that devices meet your organization’s baseline security posture. The compliance baseline isn’t punitive; it’s the minimum acceptable security threshold. Conditional Access policies form the final leg of the prerequisite triangle. These aren’t optional — they’re how you enforce the “trust zero, verify always” principle of Zero Trust. The National Institute of Standards and Technology defines Zero Trust architecture as requiring continuous verification and explicit access grants based on all available data points. I configure policies that require device compliance, enforce multi-factor authentication for sensitive operations, and block legacy authentication entirely. The policy I typically recommend as a starting point requires hybrid-joined devices, compliant Intune status and MFA for all access to on-premises resources, while allowing seamless sign-in for fully compliant devices. This creates a virtuous cycle where security and user experience reinforce each other. Architecture decisions: Hybrid authentication flows and Windows Hello for Business Once your prerequisites are in place, you face critical architectural decisions that will shape your deployment for years to come. The primary decision point is whether to use Windows Hello for Business, FIDO2 security keys or phone sign-in as your primary authentication mechanism. In my experience, Windows Hello for Business is the foundation for hybrid environments. It leverages biometric or PIN authentication on the device itself, preventing credentials from ever being transmitted across the network. When a user signs in with Windows Hello, they’re not sending a password or even a credential — they’re using a private key stored in the device’s Trusted Platform Module (TPM) to prove their identity. For hybrid-joined devices, this works seamlessly because the device can authenticate both to your on-premises domain controller (using cloud Kerberos) and to Entra ID in a single operation. This eliminates the attack surface that traditional password-based authentication creates. Organizations seeking more information on passwordless authentication approaches can review guidance from the Cybersecurity and Infrastructure Security Agency, which has published extensive recommendations on moving beyond passwords. However — and this is crucial — not all devices have TPM 2.0, which is required for the most secure implementations. In one organization where we deployed to 15,000 devices, we discovered that 12% didn’t meet hardware requirements. We ended up implementing a phased approach: Windows Hello for Business on compliant devices, with FIDO2 security keys as the backup for devices that couldn’t support it. FIDO2 keys, which conform to the open FIDO2 standard, are also your answer for scenarios where you need physical authentication tokens — particularly useful for privileged accounts or high-risk scenarios. They’re resistant to phishing and account takeover because possession of the physical token is required. Research from the Identity Defined Security Alliance has shown that organizations using FIDO2-compliant authenticators reduce account compromise incidents by over 90% compared to password-dependent systems. The architectural decision also includes determining how you handle legacy applications that still require passwords. Your options are limited: implement a passwordless-compatible application gateway, deprecate the application entirely or use Entra ID’s smart lockout and password protection features to reduce risk while you transition. I typically recommend treating legacy application support as a temporary bridge, not a permanent architecture. Organizations that treat this as permanent inevitably find themselves maintaining password infrastructure indefinitely, undermining the entire security posture you’re building. Migration workflows: The step-by-step reality The migration itself needs to follow a structured approach that I’ve refined across multiple organizations. Start with a pilot group — I recommend between 50 and 200 users who are willing to accept some friction in exchange for security improvements. This group should include IT staff and security-conscious users who can provide meaningful feedback without becoming frustrated with early-stage issues. For the pilot phase, configure Windows Hello for Business using Group Policy on your on-premises infrastructure for domain-joined devices, while using Intune policies for cloud-managed devices. Configure Entra ID to require Windows Hello as the preferred authentication method. During this phase, maintain traditional password authentication as a fallback — not because you lack confidence, but because user trust in the system matters. I typically see a three to four week period where you’re supporting both methods while users adapt. This period provides invaluable data about real-world usage patterns and edge cases. The second phase involves expanding to department-level groups. At this point, you should have identified and documented all the troubleshooting patterns that emerged in your pilot. Common issues I’ve encountered include PIN complexity policies that conflict with Windows Hello configuration, credential caching issues on hybrid-joined devices and confusion around how to recover access when a device is lost or compromised. A well-designed help desk knowledge base at this stage prevents the third phase from becoming a support crisis. The final phase is organization-wide rollout with password authentication disabled. This is where you must have complete confidence in your fallback mechanisms and your support team’s ability to handle edge cases. I recommend maintaining password authentication for break-glass scenarios (though heavily restricted and logged) for at least 90 days after full rollout. This safety net provides psychological comfort to leadership and creates a genuine escape hatch if something unexpected occurs at scale. Troubleshooting patterns and lessons learned After guiding three large-scale deployments, I’ve compiled a list of issues that deserve attention before they become production problems rather than documented solutions. Device compliance checking often becomes a bottleneck. If your Intune policies are too strict, you’ll have users locked out of passwordless authentication because their devices are non-compliant. The solution isn’t to loosen policies — it’s to automate compliance remediation. Use Intune’s remediation scripts to automatically enable required features and update settings rather than blocking access. When a device becomes non-compliant due to a missing security update, remediation scripts can deploy that update silently, restoring access without support interaction. Cloud Kerberos ticket refresh failures occur when devices lose network connectivity. I’ve found that users appreciate understanding that brief network outages might require them to use an alternative authentication method temporarily. Documenting this expectation and providing clear error messages reduces support burden significantly. One organization I worked with created a simple status dashboard showing cloud connectivity health, which dramatically improved user confidence in the system. The Windows Hello PIN reset flow needs careful planning. Users will forget PINs — not because they’re careless, but because they now have one less password to remember and are redirecting that cognitive effort elsewhere. Implement Entra ID’s self-service PIN reset capability, but test it thoroughly in various network conditions. I discovered in one deployment that users couldn’t reset their PIN while offline, which created support tickets even though the feature was technically available online. A simple offline reset option would have eliminated those tickets. Recovery mechanisms deserve special attention. What happens when a user’s device is stolen? What if the TPM fails? What if they forget their PIN and can’t reach your self-service portal? Document these scenarios and test them with your help desk before full rollout. I’ve found that help desk confidence in recovery procedures directly correlates with user confidence in passwordless authentication. The endpoint: A genuinely passwordless enterprise Reaching true passwordless authentication in a hybrid environment means accepting that you’re building a new security model, not just changing how users authenticate. The effort required is substantial, but the security improvement is profound. I’ve watched organizations move from breach-heavy authentication scenarios to Zero Trust architectures where every access request is evaluated in context, and where the compromise of a single device doesn’t cascade into wholesale account takeover. The passwordless journey isn’t a destination you reach in months — it’s a direction you move in consistently. The organizations that succeed view passwordless migration not as a project with an end date, but as a fundamental shift in how they think about identity and trust. They maintain that momentum by continuously updating policies, expanding coverage to new applications and use cases, and refining their architecture as technology evolves. The view from the other side is worth the journey. Once you’ve lived in a passwordless environment, going back to password-based authentication feels like removing your seatbelt during a drive. The risk seems obvious in retrospect, and the safety you’ve gained becomes non-negotiable. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Eye Security’s 2026 State of Incident Response Report shows that cyberattacks on companies are increasingly going undetected, and the damage occurs within minutes. According to the report, attackers are now focusing less on hacking systems and more on exploiting existing access points. Identity-based attacks dominate the field, with passwords being involved in 97% of incidents tracked by Eye Security. Abuse of legitimate accounts is a primary cause of cloud security incidents and drives the business of initial access brokers. However, the study’s results show that attackers’ fundamental methods remain unchanged. “Even in 2026, compromise will still begin with phishing, exploiting misconfigured or vulnerable internet-enabled systems, social engineering, or attacks via the software supply chain,” explains Lodi Hensen, VP of security operations at Eye Security. BEC attacks are particularly common Business email compromise (BEC) is the most common form of attack, according to the study: More than 70% of incidents fall into this category. In 40% of these cases, phishing served as the initial point of entry. Analysts say that BEC attacks can remain undetected for weeks without continuous monitoring. Furthermore, the study highlights that ransomware remains one of the biggest threats. “The proliferation of Ransomware-as-a-Service (RaaS), BuilderLeaks, and access broker marketplaces has lowered the barriers to entry and created a professional ecosystem,” the authors explain. The report reveals a dangerous trend: the commercialization of insider knowledge. “Groups like ShinyHunters are actively recruiting employees to buy access credentials. This blurs the line between external attacks and insider threats,” the security researchers explain. “For ransomware actors, this purchased access is often faster and more reliable than technical hacking.” Companies in the industrial, construction, and transport and logistics sectors are particularly affected. Many ransomware attackers exploit everyday vulnerabilities: unprotected applications, insecure remote access, or phishing emails through which employees unknowingly disclose login credentials. The analysis evaluated a total of 630 security incidents in Europe from 2023 to 2025. View the full article