Microsoft confirms Office LTSC 2021 support ends October 2026, urging businesses to move to Microsoft 365 or LTSC 2024.



Microsoft is shutting down several of its products this year, including, but not limited to, the Access Database Compare tool, Publisher, and Outlook Lite on Android. Now, Microsoft has reminded customers that another suite of apps is set to retire this year, and also suggested an alternative.

Office LTSC 2021 suite and the standalone applications that it comprises of are facing the chopping block on October 13, 2026. As is common in these scenarios, these pieces of software will continue to function but they will not receive any security fixes, patches for bugs, or technical support from Microsoft. What this also means is that if you face any sort of issue, such as a break in compatibility, you are not guaranteed any assistance from Microsoft.

The Redmond tech giant has suggested multiple upgrade paths for small businesses and large enterprise organizations. For the former entities, those with fewer than 300 seats, the following are viable alternatives as long as you are OK with being connected to the cloud:

   • Microsoft 365 Business Premium

   • Microsoft 365 Business Standard

   • Microsoft 365 Apps for business

Meanwhile, larger organizations should consider the following:

   • Microsoft 365 E3

   • Office 365 E3

   • Microsoft 365 Apps for enterprise


These Microsoft 365-powered versions of Office applications offer better security, management capabilities, and compliance. In addition, it also includes Copilot integration, can be installed on multiple devices per user, and dynamic updates that keep you always updated.

However, for those who are more comfortable with the on-premises variant of Office and want to continue down that path, Office LTSC 2024 is still an option. This is the most recent version of on-prem Office for commercial LTSC customers and also includes new versions of Visio and Project. Do choose your migration path carefully though, because Office LTSC 2024 will reach end of support on October 9, 2029.

source

Windows app development shifted from a single stable model to multiple frameworks

When WhatsApp made the universally hated decision to switch its native Windows app to a web wrapper, most of the criticism was directed at Meta. And rightly so. It felt lazy, it was a clear, RAM-hogging downgrade, and it removed what little “native” experience the app had on Windows.

But the reality is a bit more uncomfortable.

Even Meta didn’t have much incentive to stick with a native Windows app. The company barely updated it, didn’t bring feature parity, and eventually defaulted to the web version instead. The main reason is probably for the fact that web apps are cheaper to build and maintain. But the actual issue is that Microsoft hasn’t given developers a UI framework they can commit to in the long term. Web apps don’t have that problem.



We recently heard from a long-time Windows Latest reader, Alexander Ovchinnikov, who also happens to be a developer. His points echo what a lot of developers already feel.

Unlike macOS, which always gets native apps, despite having a much smaller user base, developers’ attitude toward pushing web apps just for Windows isn’t about convenience. It’s about trust, or rather, the lack of it.

Over the years, Microsoft has introduced multiple “future” frameworks, only to move away from them later. From WPF and Silverlight to UWP and now WinUI 3, the company hasn’t changed this pattern. As Alexander puts it, many developers now assume that whatever Microsoft is pushing today might not last long enough to justify building on it.

Microsoft hasn’t had a clear GUI strategy in decades, and Windows now offers too many frameworks without a definitive answer on what developers should actually use.

Knowing this changes the outlook I had on web apps for Windows. They’re a fallback option when the platform itself feels uncertain. However, Microsoft’s recent love for making 100% native apps for Windows may turn things around.

Windows went from one clear development path to too many confusing choices

There was a time when building a Windows app didn’t require a mental debate. Early Windows development revolved around a single, well-understood approach. Win32 was the answer. One API, one mental model, and a clear way to get things done.

Charles Petzold’s “Programming Windows”, which was universally regarded as the “Bible” of Windows development, made it accessible, and developers could invest their time knowing the platform wasn’t going to shift under their feet. That stability created trust, and trust made the ecosystem grow.

However, instead of evolving Win32 into something more modern, Microsoft kept introducing new layers and alternatives. First came MFC as a C++ wrapper. Then WinForms for .NET developers. WPF followed with XAML and hardware-accelerated rendering. Silverlight showed up as a cross-platform bet. Then came WinRT and UWP during the Windows 8 and Windows 10 era. And now we have WinUI 3 with the Windows App SDK, alongside MAUI for cross-platform development.

Each of these was announced with a strong pitch about being the future of Windows development. Each one asked developers to invest time, learn new patterns, and build on top of it.

The issue wasn’t that these technologies were bad. Many of them were genuinely ahead of their time. The problem was that the “future” kept getting replaced before it could fully settle. Instead of a single evolving platform, developers were left chasing moving targets.

Jeffrey Snover’s detailed blog points out that Windows stopped having a clear answer to a simple question: how should you build a Windows app?

WPF was supposed to be the future, until Silverlight came along, which looked promising, until Microsoft pivoted to HTML5. UWP was pushed as the unified platform for everything, but never gained full adoption, even internally. WinUI 3 is now positioned as the modern solution, but its roadmap hasn’t inspired the same level of confidence developers had in earlier eras.

When Microsoft introduces a new framework with a clear direction, developers will start adopting it. Then the strategy would shift, and attention would move elsewhere. The previous framework wouldn’t always be officially killed, but it would slowly lose relevance. This cycle repeated enough times that developers stopped fully committing.

As Alexander told us, the sentiment today is, if Microsoft couldn’t stick with previous frameworks, why assume the current one will be any different?

That’s how things look today. Ask a developer what they should use for a Windows app, and the answer depends on who you ask. Some will still recommend Win32. Others prefer WPF because it’s stable. WinUI 3 is positioned as modern, but not universally trusted yet. MAUI exists for cross-platform use. Then there’s the web route with Electron or PWAs. On top of that, third-party frameworks like Avalonia and Qt are gaining traction.

This isn’t the kind of choice developers were asking for. It’s total uncertainty.

Why developers are choosing web apps instead of native

Some of the most popular Windows apps are not truly native. WhatsApp, Spotify, Discord, Slack, Notion, Zoom, and even parts of Microsoft’s own ecosystem…Microsoft Teams (before its rewrite), Clipchamp, and several first-party experiences use WebView2.


Microsoft Clipchamp

Of course, it has become so easy to build a web app once and ship everywhere. It can run on Windows, macOS, Linux, and even inside a browser without maintaining separate codebases. Frameworks like Electron, Chromium-based WebView, and Progressive Web Apps have made distribution simpler, updates faster, and development costs lower. Companies find it hard to ignore.

Microsoft’s pivot to WebView2 embeds the Edge (Chromium) engine inside apps. It works well for consistency, but it also means many “desktop” apps are just web pages running in a container.

And the obvious downside is that these apps consume more RAM, feel less responsive, and don’t integrate as deeply with the OS. Running multiple Electron apps at the same time can easily eat through system resources, something native apps traditionally handled much better.


“WhatsApp” is new version and “WhatsApp Beta” is old UPW/WinUI in the screenshot

On macOS and iOS, developers still prioritize native apps. Even companies that have web technologies elsewhere build native versions for Apple devices. That’s because Apple has maintained a much clearer development path. Frameworks like Cocoa, AppKit, and now SwiftUI have been consistently supported and evolved. Developers know what to use, and more importantly, they know it will still be relevant years later.

Windows doesn’t have that same clarity, and developers respond accordingly.
So instead of betting on a framework that might change direction again, many choose the web. It’s not perfect, and in many cases, it’s objectively worse for desktop performance. But it removes the bigger risk of depending on Microsoft’s next decision.

Microsoft is trying to fix this, but it may be too late

There are signs that Microsoft is aware of the problem. Recent efforts suggest them moving toward improving performance, reducing reliance on web-based components, and building more native experiences across Windows. Rudy Huyn’s X post welcoming Windows developers to build 100% native apps has been looked upon in a positive light.
But fixing the apps themselves is only one part of the equation.

Even if Microsoft delivers better native apps going forward, developers are still going to hesitate. The hesitation doesn’t come from what WinUI 3 can or cannot do today. It comes from what happened to everything that came before it. Years of shifting priorities have made developers cautious, and that kind of hesitation doesn’t disappear overnight.

If Microsoft wants to change that, it should fully commit to one framework and communicate it well to developers. That also means sticking with a framework long enough for it to mature, making its direction clear, and supporting it. Developers need a roadmap they can trust, along with clear migration paths when changes do happen.

The real problem isn’t technology, it’s consistency

Microsoft doesn’t lack capability. The company has some of the best engineering talent in the industry and a long history of building powerful development tools. Many of the frameworks it introduced were genuinely strong from a technical standpoint.

What’s missing was and is consistency.



Rebecca Sutter’s analysis mentioned that the issue isn’t technical failure, but a pattern of internal decisions that repeatedly shift direction.

These have repeatedly translated into uncertainty for developers. From the outside, it doesn’t matter why those changes happened. What matters is the result. Developers were left with multiple paths, none of which felt guaranteed to last.

That’s why the situation looks the way it does today. The problem isn’t that Windows has too few options. It’s that none of them feels definitive. Developers are not asking for more frameworks. They’re asking for one they can trust.

Web apps are a symptom, not the problem

Web apps are not taking over Windows because they’re better suited for desktop computing. In many cases, they aren’t. They’re taking over because they offer reliability to developers who no longer want to invest in the Windows platform.

Developers can’t be blamed for making a calculated decision based on past experience.

If Microsoft wants to improve the quality of apps on Windows, the solution isn’t just committing to fix Windows 11 and build native first-party apps, but rebuilding trust with developers and proving that this time, the platform (WinUI3, I hope) will stay consistent.

source

Microsoft researchers found a campaign that abuses WhatsApp attachments to sneak a script onto Windows machines which will lead to the attacker gaining remote control.

WhatsApp offers a desktop application for Windows and macOS, which users can synchronize with their mobile devices. Desktop versions of WhatsApp are generally used as extensions of mobile apps rather than primary platforms. So, while wide usage of these apps exists, their adoption rate is likely significantly lower when compared to mobile platforms.

Last year, we wrote about Meta closing a vulnerability that allowed an attacker to run arbitrary code on a Windows system which existed in all WhatsApp versions before 2.2450.6.

The attacks found by Microsoft however are based solely on social engineering. The target receives a WhatsApp attachment that looks harmless enough, but it is actually a .vbs (Visual Basic Script) file that Windows can execute.

If the attacker manages to convince the victim to run the file on Windows, the script copies built‑in Windows tools into a hidden folder and gives them misleading names so they look harmless at first glance.

And the tools themselves are legitimate ones, but they’re abused to download malware. A classic living off the land (LOTL) technique which uses what’s already on the system instead of introducing malware binaries that would get picked up in a scan.

The next scripts are pulled from popular cloud providers, so network traffic looks like normal access to AWS, Tencent Cloud, or Backblaze instead of some shady server that would raise red flags.

To turn off other possible alarms, the malware keeps trying to elevate itself to administrator, then tweaks UAC (User Account Control) prompts and registry settings so it can silently make system‑level changes and persist across reboots.

At the end of the infection chain, an unsigned MSI (Microsoft Installer) sets up remote‑access software and other payloads, giving the attacker ongoing, hands‑on access to the machine and data.

How to stay safe

For home users and small businesses, there are some practical steps to stay safe:

■ Do not open unsolicited attachments until you have verified with a trusted source that they are safe.

■ Turn on View File name extensions in Explorer so that a file claiming to be picture but ending in .vbs or .msi can be identified as such.

■ Use an up-to-date real-time anti-malware solution to stop unwanted connections and identify malicious files.

■ Download software only from the vendor’s official site and check that installers are signed.

■ Don’t ignore warning signs. Unexpected UAC prompts, new software suddenly appearing, or your machine becoming sluggish after opening a WhatsApp attachment are all reasons for an anti-malware scan and, if needed, be prepared to restore from a clean backup.

■ Keep Windows and all other applications current to prevent from exploiting known vulnerabilities.

source

Browser-based attack techniques are behind the biggest breaches today.

Learn how they’re bypassing cybersecurity controls and what security teams can do about it.



The browser is the new battleground

Modern breaches begin in the browser.
Often, they never leave it.

Many modern breaches happen entirely in the web browser. Attackers target your users as they go about their work, intercepting them as they access legitimate, trusted websites.

Where we used to talk about novel software exploits and advanced endpoint malware, in 2026 we’re instead talking about cloud apps and identities as the “patient zero” of modern breaches.



Attackers are turning to browser-based TTPs
Attackers are innovating fast.

Attackers in 2026 are using a wide (and growing) range of browser-based techniques to achieve a common goal: compromise cloud applications and services accessed over the internet, and ultimately profit from data theft, disruption, and extortion. This is now the primary attack path.

We break down all of the major techniques, analysing in-the-wild use of AITM phishing, malicious OAuth apps, malicious browser extensions, credential stuffing (& ghost logins), ClickFix (and the family of *fix variants), and session hijacking.

Legacy tools can’t keep up

The browser is a blind-spot for most security teams.

Browser-based attacks are so effective because they find ways around many traditional control points and security tools.

It’s essential that blue teamers leave “list thinking” behind and re-evaluate whether their controls are providing the protection they thought they did.

FBI, CISA warn of Russian hackers hijacking Signal and WhatsApp accounts!

In a Public Service Announcement (PSA) the Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) warn the public about ongoing Russian-linked phishing campaigns that aim to gain access to messaging accounts.

Earlier this month we wrote about a large‑scale phishing campaign aimed at hijacking Signal and WhatsApp accounts belonging to senior officials, military personnel, civil servants, and journalists.

Now the FBI and CISA have joined European intelligence services in warning that the same tactics are being used in a broader campaign targeting these commercial messaging apps. The goal is not to break end‑to‑end encryption, but to walk straight around it by stealing access to individual accounts.

In our previous article, we focused on warnings from the Dutch intelligence services AIVD and MIVD, which described how Russian state‑backed actors approached high‑value targets via Signal and WhatsApp, posing as “Signal Support”, “Signal Security Bot”, or similar. The PSA demonstrates how the same groups are now running global phishing campaigns against messaging app accounts, with evidence suggesting thousands of compromised accounts worldwide.

It’s important to reiterate that the attackers have not managed to break the apps’ end-to-end encryption. Instead, they are relying on social engineering to get a device added so they can eavesdrop on accounts.

The current targets include current and former US government officials, military staff, political figures, and journalists, but there is nothing to stop the same techniques being reused against businesses and everyday users.

So, while it’s tempting to dismiss this as a problem for diplomats and generals (and the agencies issuing these alerts do mention high‑profile targets first), the techniques scale very easily. Once playbooks like these are public, they tend to be copied by cybercriminals looking for new ways to steal money or accounts.

How to protect your accounts

As the PSA puts it:

“Phishing remains one of the most unsophisticated, yet effective means of cyber compromise, often rendering other protections irrelevant”

This calls asks for basic security measures:

• Treat unsolicited messages from “Support” inside apps as suspicious by default. Legitimate support for apps like Signal and WhatsApp does not ask you, in a chat message, to send back verification codes, PINs, or passwords.​ If you receive a warning about account problems, do not follow links in the message. Open the app’s settings directly or visit the official website through other means.

• Never share SMS verification codes or app PINs. SMS codes are there to prove that you control a phone number. Anyone who has the code can pretend to be you. App‑specific PINs or passcodes are there to protect account changes. Giving them away is like handing over the keys to your account. Consider anyone asking for them to be a scammer.

• Be careful what you discuss and with whom. Both the Dutch and US advisories remind us that even with end‑to‑end encryption, some conversations are too sensitive for commercial chat apps.

• Use the extra security features these apps offer. Enable options like registration lock, registration PIN and device‑change alerts so that your account cannot be silently re‑registered without an extra secret. Store your PIN in a password manager instead of choosing something easy to guess or reusing a common code, to reduce the chance of social engineering or shoulder‑surfing.

• Another useful feature is disappearing messages. Short‑timer and disappearing messages reduce how much content is available if an attacker gets into a chat later, or if someone obtains long‑term access to a device or backup. They are not a complete solution, but they can limit the damage.

What to do if you think your account was hijacked

If you suspect an attacker has taken over your messaging account:

1. Try to re‑register your number in the app immediately to kick out other devices.

2. Revoke all linked devices and change any app‑specific PINs or lock codes.

3. Warn your contacts that someone may have impersonated you and ask them to treat recent messages with caution.

4. Review recent conversations for signs of data theft (for example, shared IDs, documents, or passwords that should now be considered exposed).

5. Report the incident to the app provider and, where appropriate, to national reporting centers such as the FBI’s Internet Crime Complaint Center (IC3) at ic3.gov or the relevant authority in your country.​

The sooner you act, the smaller the window in which attackers can exploit your account.

source