We recently released support for Exposure Management Authenticated Scanning on Windows, using SSH.

Here we will explain the steps needed to ensure your Windows host can be connected to via SSH.

This article applies to the following:

• Windows Server 2019
• Windows Server 2022
• Windows Server 2025
• Windows 10 / Windows 11 (optional)

Enabling SSH

To allow secure remote access to a windows device, the SSH service must be enabled.

Windows Server supports SSH through the built-in OpenSSH Server feature, which allows encrypted remote connections and command-line access. [learn.microsoft.com]

Follow the steps below to install and enable SSH on Windows Server.

1. Verify OpenSSH Server availability

Open PowerShell as Administrator and run:

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Server*'

• If the state is “Installed”, skip to step 3.
• If the state is “NotPresent”, proceed with installation.

2. Install OpenSSH Server

Run the following PowerShell command:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

This installs the built-in OpenSSH Server component available in modern Windows versions.

3. Start and enable the SSH service

After installation, start the SSH service from PowerShell:

Start-Service sshd

Set it to start automatically at system startup:

Set-Service -Name sshd -StartupType Automatic

This ensures SSH remains available after reboot.

Allow SSH traffic in Windows Firewall

To allow inbound SSH connections (default port 22), create a firewall rule using PowerShell:

New-NetFirewallRule -Name "OpenSSH-Server" `

-DisplayName "OpenSSH Server (sshd)" `

-Enabled True `

-Direction Inbound `

-Protocol TCP `

-Action Allow `

-LocalPort 22

This enables remote systems to connect via SSH.

Verify the SSH service

Check the service status from PowerShell:

Get-Service -Name sshd

• Status should be Running

Test SSH connectivity

From a remote machine, connect using the following from a command prompt:

ssh <username>@<server-ip>

Example:

ssh administrator@192.168.1.10

Key-based authentication (recommended)

It is strongly recommended to use Key-based authentication instead of passwords, this is more secure in the long term.

Generate your private/public key pair as usual or by using instructions in step 1 Key-based authentication (recommended) | Radar | 4.0 | WithSecure User Guides

Append your public key to C:\ProgramData\ssh\administrators_authorized_keys file.

Note: standard users use personal C:\Users\username\.ssh\authorized_keys file, but for administrator permissions, global administrators_authorized_keys file is used.

Verify that the correct key is present, and the file is formatted correctly.

ssh-keygen -l -f "C:\ProgramData\ssh\administrators_authorized_keys"

Note: A very common mistake is using invalid line ending characters. Please make sure only Linux line endings “\n” are used.

Make sure file has correct permissions set

icacls "C:\ProgramData\ssh\administrators_authorized_keys"

Should only show two entries:

NT AUTHORITY\SYSTEM:(F)BUILTIN\Administrators:(F)

Verify that key authentication works

ssh –i <private_key> <username>@<server-ip>

Example:

ssh –i .ssh/id_ecdsa administrator@192.168.1.10

Additional notes

• OpenSSH Server is included as a built-in feature starting from Windows Server 2019 and later.
• SSH uses encrypted communication to protect data integrity and prevent eavesdropping.
• The default SSH port is TCP 22, which must be allowed through firewall configuration.

On Sun 7th June 2026, 18:00 UTC we are planning to upgrade RBAC Access Control System database in the production WithSecure Elements environment.

Access control system will be running in read-only mode for up to 2 hours:

• Changes in the Security Administrators view will not have any effect. All changes will be delayed and applied after upgrade has finished
• Access Control View (participants of RBAC pilot only) will be available in read-only mode – any change in role assignments, users and security groups will not be possible

Other parts and features or the Elements Security Center are not affected

Security (cloud) services, agents (clients), and APIs are not affected during this maintenance break.

We recommend that Users should plan and execute urgent access control changes prior to the upgrade window.

We have observed that some of our partners and customers are calling the Security Events endpoint of the Elements API, requesting several years of event data.

This can cause an increased data processing load for the API consumer, and will also affect them in the longer term. Read on for more details.

This is creating an abnormal load on our API, which can be impactful to both WithSecure and our other customers.

Facts

• Older Security Events are never updated, so if you have retrieved them once there is no need to retrieve them again. Retrieving them again incurs bandwidth usage and processing cycles both for you and for WithSecure.
• We have a limitation of 30 days of Security Events per request, although this is not currently enforced. From the documentation on Security Events, we have the following:

Recommendations

• Only collect the full range of events once and store them for future use
• Only request a maximum of 30 days of events per request
  • If you need to request 90 days of data, you can make 3 requests for 30 days each

Recommended Polling Pattern for Integrations (SIEM, Data Lakes, etc.)

For integrations that continuously ingest Security Events (e.g., SIEM pipelines), we strongly recommend using an incremental polling approach:

• Poll the Security Events endpoint at a regular interval (e.g., every 5–15 minutes).
• In each poll, request only new or updated events since your last successful request by using the persistenceTimestampStart parameter.
• Maintain a checkpoint (e.g., last seen persistenceTimestamp) in your system to ensure continuity between requests.

Example pattern:

Initial fetch:

• Retrieve a historical dataset once (e.g., last 30–90 days, split into 30-day windows).
• Store the latest persistenceTimestamp from the response.

On subsequent polls:

• Use the stored timestamp as persistenceTimestampStart
• Set persistenceTimestampEnd to the current time
• Retrieve only newly available events

Future Changes

We will start enforcing the 30 day limitation per request starting from September 7th 2026.

We are happy to introduce Dark Mode in the Elements portal. This much-requested feature gives users a more comfortable viewing experience in low-light environments, supports work in control rooms and during night shifts, and offers another way to personalize the interface based on individual preference.

Background

Dark Mode has been one of the most requested improvements for the Elements portal for some time. Many users spend long periods in the portal in environments where bright interfaces can be distracting or tiring, especially in control rooms or during work in darker settings. With this update, the interface can now be viewed in a darker color scheme that feels easier on the eyes while keeping the familiar Elements experience.

What does this change for you?

Dark Mode gives you more flexibility in how you use the Elements portal. You can switch to a darker interface when working in low lighting, when monitoring activity in control room setups, or whenever you simply prefer a darker visual style. The goal is to make everyday use more comfortable without changing how you navigate or use the product.

How to get started

Getting started is simple. Open your user profile menu in the Elements portal and use the selector to switch between Light Mode and Dark Mode. The change takes effect directly in the portal, making it easy to choose the view that works best for your environment and personal preference.

Extended Detection and Response

Endpoint Protection

WithSecure Endpoint Security Portal

Following are the improvements we have made in the Endpoint Security Portal:

Improved user-facing message on attempt to delete view template that is used for updatable email reports.

Manage Operations screen optimized for large volumes of operations

To prevent timeouts for large partners, the Manage Operations screen now shows only the most recent 1,000 operations. If a partner has fewer than 1,000 operations, all are displayed and no flyout appears.

Added luminen animation to the reports

WithSecure Elements Agent for Mac

WithSecure Elements Agent macOS 26.2.55744 has been released.

This release brings

• Updated sensor component
• Updates to the Software updater component
• Bug fixes to client side support of software inventory feature (available later in 2026)

The Installer can be downloaded from

https://download.withsecure.com/PSB/latest/ElementsAgentInstaller_55744.mpkg

Elements Agent macOS 26.2.55744 supports following macOS versions:

• macOS 26 Tahoe
• macOS 15 Sequoia
• macOS 14 Sonoma

Elements Agent for Android

An update to the WithSecure Elements Mobile Protection app for Android (26.3.0023571) has been released.

Fixed issues:

• The Antivirus system scan no longer shows an incorrect “Incomplete” status
• The app now allows changing the state for recently created domains in the app UI
• The app no longer fails to apply App exceptions configured via the portal profile

Elements Agent for Windows and Server

A new version of the endpoint clients is available and existing customers have been automatically updated.

This release makes the Elements Agent version 26.2 available (internal version 26.2.301).

The endpoints automatically upgrade, without a reboot.

This release introduces new features (with Profile Editor Update).

Browser Extensions Tab in Settings

A new “Browser Extensions” tab has been added to the Settings dialog. This tab shows the status of the Browsing Protection extension for each installed browser and provides options to open the browser’s extension store or copy the installation link.

New Network Isolation Security Events

Two new security events have been introduced to enhance visibility into network isolation actions.

“Computer has been isolated from the network”

“Computer has been released from the network isolation”

Remote Operation to Reset Security Cloud Cache

Added a new remote operation to reset the Security Cloud cache.

Enhanced Malware Protection Status Reporting

Improved the reporting of malware protection unload status during service startup.

Endpoint Detection and Response

To help you create more flexible and maintainable suppression rules, wildcards are available for Accepted Behavior suppression rule parameters. Wildcards allow you to match patterns instead of exact values, making it easier to suppress recurring or similar events without creating multiple rules.

What are wildcards?

Wildcards let you define suppression rules using partial matches rather than exact strings. This is especially useful when values vary slightly, such as file names, paths, or user names.

The following wildcard characters are supported:

• * – matches any sequence of characters (including empty)
  
  Example: *.exe matches file.exe, test.exe, .exe
• ? – matches any single character
  
  Example: file?.txt matches file1.txt, fileA.txt

To treat wildcard characters as literal values, use the backslash (\) as an escape character:

• \* – matches a literal asterisk
  
  Example: test\*.txt matches test*.txt
• \? – matches a literal question mark
  
  Example: test\?.txt matches test?.txt

Supported parameters

Wildcards are supported in suppression rules for Accepted Behavior when matching the following parameters:

• Process name
• Process path
• Process command line
• Username
• Parent process name
• Parent process path

How to use wildcards

You can create or edit wildcard-based suppression rules in two ways:

• From Events → Broad Context Detections, when closing a detection as Accepted behavior and choosing to create a suppression rule.
• From Security Configurations → Automated actions → Suppression rules, by editing an existing rule.

In both flows, select Wildcard for the chosen parameter in the Parameters step, then define the pattern using *, ?, or escaped characters as needed.

Using wildcards helps reduce rule duplication, keeps configurations cleaner, and makes suppression rules easier to maintain over time

Exposure Management

Exposure Management Portal

Changes to the Exposure Management portal include:

• When a computer or umanaged device is restored, related findings are also restored in Exposure Management views.
• Resolved an issue with updating SSH authentication method in System Scans.
• Resolved an issue with updating TCP Scan Technique in System Scans.
• Resolved an Issue where Summary Reports failed to generate, preventing successful report creation.
• Improved Network scan tag filtering by allowing search by tag name.
• Resolved an issue on Network scans page, preventing opening device link in a new window.
• Resolved an issue where changing an Agent scan schedule could unintentionally re‑enable VM scanning that had been explicitly disabled by the user.
• Resolved an issue where new scan reports could cause findings to appear for devices that were already removed but still visible in Removed devices view.
• When the user’s name or surname is empty, the email address is displayed in multiple views.
• Resolved an issue preventing the removal of the last encryption key from the list.
• Resolved an issue where users without complete name information were displayed incorrectly. The email address is now shown when first name or last name is missing.
• Resolved an issue affecting the display of historical Web Scan reports. The report now renders correctly.
• Resolved an issue where users created in VM from ASC notifications were not properly reflected in FACS. User synchronization between systems has been fixed.
• Overall performance improvements.
• Overall security improvements.

Exposure Management System Scan

Support for detecting vulnerabilities in the following products was added to Authenticated Scanning for Windows:

• Amazon Athena ODBC Driver
• Arcserve UDP Console
• Dell PowerProtect Agent Service
• Devolutions Gateway
• ESET Protect
• HCL Traveler
• HP Device Manager
• IDrive for Windows
• Lenovo Diagnostics
• Lenovo Software Fix
• Malwarebytes Anti-Malware
• Podman Desktop
• Sentinel LDK
• TrueConf client
• Voidtools Everything

Support for detecting vulnerabilities in the following products was added to Authenticated Scanning:

• Elastic OTel Java
• pac4j-jwt
• Spring AI

Additionally, we added detection for vulnerable Axios library versions and support for detecting CVE-2026-40175 vulnerability. See this article for more information.

Exposure Management for Cloud

Improvements to Exposure Management for Cloud include:

• Fixed bug with first scans not being scheduled to run for certain accounts
• Performance and stability improvements
• New AWS rules:
  • Amazon Bedrock lacks account-level guardrails
  • Amazon Bedrock lacks organization-level enforced guardrails
  • Amazon Bedrock agent does not have a guardrail configured

Elements Foundations

Elements Security Center

Enhanced “My Reports”

We are excited to introduce new enhancements to My Reports for MSP environments, designed to improve report management, consistency, and flexibility across organizational hierarchies.

Following are the new features

SOP administrators can now mark “My report” view templates as inheritable.

This means that:

• The template becomes visible to all underlying companies in the hierarchy
• Companies can use these templates to create reports within their own scope

Updatable Reports

Administrators can now create updatable reports that are linked to a view template.

Key benefits:

• Reports automatically reflect any updates made to the associated template
• Ensures reports stay aligned with the latest structure and data requirements
• Reduces manual updates and maintenance

Important notes:

• This feature works only with organization-level or inherited view templates
• For inherited templates, it is now possible to include a partner logo in the generated PDF reports

Limitations:

• Previously created reports cannot be converted into updatable reports
• Once a report is created as updatable, it cannot be reverted to a non-updatable report

Integrations

Commercial API

Updated Documentation: all ‘/subscriptions’ endpoints combined to a single List Subscriptions endpoint with filter parameters

We’ve updated the documentation presentation for the following Commercial API endpoints to align with OpenAPI 3 specification requirements:

• Get subscription by buyer assigned account id
• Get subscription by reseller account id

Both endpoints share the same base URL but differ only by query parameters.

To comply with OpenAPI 3 YAML standards, they are now documented as a single endpoint: List Subscriptions.What changed:

• The above endpoints are now combined under List Subscriptions in the documentation
• Query parameters (buyer_assigned_account_id, reseller_account_id) are available as filters within the same endpoint
• Documentation structure updated to meet OpenAPI 3 requirements and improve compatibility with API tools

What did NOT change:

• No changes to endpoint logic or behavior
• No changes to request/response formats
  • Existing integrations using:
  • GET /subscriptions?buyer_assigned_account_id={buyer_assigned_account_id}
  • GET /subscriptions?reseller_account_id={reseller_account_id}
    
    continue to work exactly as before

This update is documentation-only and ensures consistent representation of the API without impacting functionality.

In case you missed it

Windows ARM64: Response Actions Support Now Available 

We are pleased to inform that response actions are now supported on Windows ARM64 systems. 

Windows ARM64 support has already been available for the Endpoint Protection Platform (EPP) and the EDR sensor. With this update, response capabilities are extended to Windows ARM64 endpoints, completing functional parity with other supported Windows architectures for Endpoint Detection and Response (EDR).

You can find out more about this release in our dedicated article.

Changes in Exposure Management

Coming slightly later than April, but important enough to communicate here, we made some important improvements in Exposure Management during late April and early May.

You can find out more information in the Exposure Management Changelog.

Share your ideas with us

Our purpose is to co-secure the world with you – now as WithSecure™. To co-create the best possible cyber security products and services, we warmly recommend you share your ideas via the Ideas section of the WithSecure Community, now accessible directly from WithSecure™ Elements Security Center.

Further information

Changelogs and Release Notes for all parts of WithSecure™ Elements can be found at the Help Center

In case you missed it:

UPDATE 2026-05-13: This has now been released to production with version “2026-05-13_01“

We will soon be releasing a major update for our Capricorn engine, used by our Endpoint Protection products. This is expected to be released on May 12th 2026. 

This will result in a larger download as an updated version of the virus definition files are distributed. 
 

 
Key improvements 

Optimized databases through consolidation of overlapping detections, resulting in: 

• Smaller footprint: Size on disk expected to decrease by ~160MB, decreasing by about half. 
• Faster updates and reduced initialization disk I/O due to reduced database size 

Update Details 

• Platform coverage: This update applies to all WithSecure Endpoint Protection products — across Windows, Mac, and Linux platforms that utilize the Capricorn engine. 
• Download size: All affected endpoints will now download a larger one-time update package of approximately 130-150 MB during the rollout. 

Deployment 

• The update will be delivered automatically. 
• No manual action or configuration is required. 
• The release time will be confirmed 24 hours in advance through our community channels. 
• Updates containing this release will start with “WithSecure Capricorn Engine (2026-05-xx-xx)”. 
• With this update, you can expect leaner, faster, and more efficient endpoint protection — without compromising security. 

We would like to inform you about an upcoming change to the TLS certificates used by the WithSecure GUTS2 Server (definition update backend), planned for May 19, 2026.

We are transitioning from DigiCert to Let’s Encrypt certificates. This update aligns our backend infrastructure with our existing services, where Let’s Encrypt is already in use, and helps us streamline certificate management while maintaining industry‑standard security practices.

What does this mean for you?

• No changes are expected for the majority of environments.
• The change will be transparent if your system trusts the ISRG Root X1 certificate (the root certificate used by Let’s Encrypt).

Common environments where no action is required:

• Windows systems with Windows Update enabled
• Environments where automatic root certificate updates are allowed (not restricted by GPO / MDM policies)
• Systems where ISRG Root X1 is not explicitly removed or blocked

When action may be needed:

• Systems with restricted certificate updates
• Environments with custom trust stores
• Devices where ISRG Root X1 is missing or not trusted

In such cases, please ensure that the ISRG Root X1 root certificate is present in your trust store.

WithSecure products currently require the following root certificates for TLS communication to WithSecure backends, therefore must be present on all machines, across all Operating Systems:

• Amazon Root CA 1 
• Amazon Root CA 2 
• Amazon Root CA 3 
• Amazon Root CA 4
• Starfield Class 2 Certification
• Starfield Services Root Certificate Authority – G2 
• DigiCert Global Root CA 
• ISRG Root X1
• ISRG Root X2

All of these are included in the default trust stores of modern, up-to-date operating systems and should not require manual installation in the majority of deployments.

We have now released a hotfix for the Windows and Linux versions of WithSecure Policy Manager 16.11.

This hotfix addresses a vulnerability on the Axios library used by Policy Manager Web Reporting.

WithSecure Policy Manager is not itself vulnerable, but we strongly advise our partners and customers to update to Hotfix 1 at their earliest opportunity.

The hotfix can be found at Policy Manager support pages, for both Windows and Linux.

For more information on the Axios vulnerability itself, please see https://community.withsecure.com/announcements-en/kb/articles/32898-cve-2026-40175-for-axios-javascript-library

What is Axios?

Axios is a JavaScript library intended to ease interaction with internet HTTP services. It is used by some organizations to simplify their codebase compared to using standard browser functionality.

What is the vulnerability?

Prior to version 1.15.0, the Axios library is vulnerable to a specific “Gadget” attack chain that allows Prototype Pollution in any third-party dependency to be escalated into Remote Code Execution (RCE) or Full Cloud Compromise (via AWS IMDSv2 bypass).

Ref: https://nvd.nist.gov/vuln/detail/CVE-2026-40175

Has the vulnerability been fixed?

This vulnerability has been fixed in 1.15.0.

What are WithSecure’s recommendations for partners and customers?

We recommend partners and customers who use Axios act immediately to ensure their systems are not vulnerable.

WithSecure Exposure Management can detect and notify partners and customers that they have a vulnerable version.

Detection for vulnerable versions is available in unauthenticated scanning, and we are investigating the possibility to detect them on hosts via authenticated scans

What is the status of WithSecure systems in relation to this vulnerability?

WithSecure has thoroughly checked its own systems, and has confirmed that all services using Axios are using the latest version which is not vulnerable.

Are any WithSecure products affected?

WithSecure Policy Manager does contain a vulnerable version of the Axios library, and we have created a hotfix for this issue. We advise all our Business Suite partners and customers to apply this hotfix at the earliest opportunity.

The risk can further be mitigated by ensuring that Policy Manager’s Web Reporting interface is not accessible from the internet. This can be done with external firewall configurations.

The hotfix can be downloaded from the WithSecure Download Center.

In May 2024 we are releasing new versions of Countercept Agents for Windows, Linux and Mac platforms. Managed clients will get all these changes automatically. A little later we will publish new release groups to switch clients using managed updates in collaboration with the WithSecure Engagement team.After the upgrade new versions of Countercept Agents will start using new addresses.

For many customers, WithSecure products will function correctly without needing to know which servers the products connect to.

However, some administrators tightly control which network addresses they allow their clients to connect to (“Egress control” or “outbound connections”), and it is mandatory that they allow connections to the following addresses. WithSecure cannot guarantee the functionality of the products if access to these addresses is blocked.

The product may not function correctly if access to these network addresses is not allowed.

Please note that all the following require outbound connections to TCP/443 unless otherwise stated.

Additionally, any products listed in this document also includes F-Secure branded versions of the same products.

Recommendations

WithSecure recommends, where possible, that administrators allow outbound access to all address under the withsecure.com and fsapi.com domains. We do appreciate that this is not always possible due to firewall configuration limitations, or even from an operational perspective, so we are publishing an explicit list of server addresses.

Please note that we do not guarantee this list of addresses is complete or will stay unchanged, so we strongly recommend bookmarking these articles for future reference. We will update these articles whenever needed.

WithSecure Countercept

New addresses

After the upgrade new versions of Countercept Agents will start using new addresses.

Please note that all the following services require outbound connections to TCP/443 unless otherwise stated.

In addition, the use of an asterisk (*) below means that all hosts under that subdomain should be allowed (wildcard allow).

• *.fsapi.com (also port 80)
• ac3ujg1ortm4c-ats.iot.eu-west-1.amazonaws.com (also port 8883, if the network includes Windows 7, Windows Server 2008 R2, or Windows Server 2012 endpoints)
• c3hquxgihnj763.credentials.iot.eu-west-1.amazonaws.com
• ew1-famp-prd-system-transfer.s3.eu-west-1.amazonaws.com
• *.digicert.com

If you are unable to allowlist wildcard, either from a technical or operational standpoint, please contact your WithSecure Engagement Manager who will be pleased to advise you further.

Connectivity Checker

We also provide tools that can assist you in checking whether your firewall allows the needed external connections.

For Microsoft Windows

Download the Connectivity Tool from WithSecure™ Support Tools library. Support Tools library, or using direct download link https://download.withsecure.com/connectivitytool/ConnectionChecker.exe

Run the tool on the machine where the installation is being attempted by double clicking on the tool through Windows Explorer. The tool will prompt for administrator credentials when it runs.

Select MDR product from the list.

If a proxy is going to be used for the installation, it must be defined when prompted. If a proxy is not going to be used, leave the proxy settings empty.

For Linux and Mac

Download the Connectivity Checker tool with the direct link https://download.withsecure.com/connectivitytool/wsconnectionchecker.zip

Unpack the tool with: unzip wsconnectionchecker.zip

Set execution bit if needed:

sudo chmod +rwx wsconnectionchecker

Run the tool in Linux or Mac mode depending on your needs. If a proxy is going to be used for the installation, it must be defined with the -p parameter. If a proxy is not going to be used use parameter ‘-d’ instead, for example:

.\wsconnectionchecker -o linux -p http://myproxy.com:3128

or

.\wsconnectionchecker -o mac -d

As Microsoft Extended Support for all Windows 8/8.1 versions ended during 2023, WithSecure will stop supporting these versions of Microsoft Windows from 31st March 2024.

This applies to all WithSecure products. This change does not affect the overall support for those products when they are used on supported operating systems.

Customers who are using these versions of Microsoft Windows are advised to upgrade them, or replace the devices, so that they can use versions of Windows that are supported by Microsoft. Both Microsoft and WithSecure strongly recommend that customers should only use supported versions of products, to maintain security and protection.

For users of WithSecure Elements, the “Devices” view can show unsupported operating systems, if the “OS End of Life” field is enabled.