FS Protection macOS releases (2025)

Release 25.5 beta 3 (build 65226)

We are pleased to announce the availability of a new release of FS Protection for macOS. This update is available for download from My FS Protection and delivery to existing installations will be started soon.

Highlight of this release:

• Addressed the known issue from 25.5 beta 2 release with logging in to an F-Secure account from a secondary macOS user account
• Included updated localizations
• Improved stability of Device Protection feature to allow a higher rate of concurrent file scan operations to complete without interruption

If you experience any issues, please report them in this forum. Please run "Support Tool" when the issue happens and be prepared to provide the resulting file if we requested. For issues related to Browsing protection and Parental control, remember to include any URLs that reproduce the problem in your bug report. You may also submit false positives and uncategorized web pages directly to F-Secure Labs using  https://www.f-secure.com/en/support/submit-a-sample

As always, we welcome any feedback via the community pages!

Hello!

25.5 beta program has ended. The version has reached general availability in production. Thanks everyone for participating!

We will continue updating this thread with the next beta version releases.  Stay tuned!

Hi, @66f2e490!

Thanks for sharing the diagnostics. I believe I managed to reproduce the issue to some degree on my end. I could not trigger the same exact prompt related to "DesktopServicesHelper" process. However, I have seen other processes that come as part of default macOS installation being marked as having invalid code signature in DeepGuard UI.

Based on my initial analysis and shared messages from your system and my test setup, DeepGuard is trying to evaluate trust for the “Software Signing” certificate that Apple uses to sign system executables. Trust evaluation fails due to "Unable to build chain to root (possible missing intermediate)" error. It makes DeepGuard display the information about OS level executables as "invalid".

According to my testing, the issue is only limited to non default DeepGuard rulesets (Classic & Strict). The default ruleset suppresses such prompts due to more permissive mode of operation.

We will need to review the logic internally with the team to come up with a fix. But as far as I could see, the main side effect of the issue is limited to the wrong description in the DeepGuard prompt when a non-default ruleset is in use.