For Windows administrators, the substantive changes include embedded Windows licensing, asset-scoped privilege elevation and updated TLS controls. One Identity’s release notes also document Microsoft Entra ID support for RDP access policies, adding a Windows-management detail beyond the announcement’s headline features.
What changes in Safeguard 9.0
It is important to separate Safeguard for Privileged Passwords (SPP) from Safeguard for Privileged Sessions (SPS) rather than treating every improvement as a suite-wide change.
One Identity’s SPP 9.0 release notes identify:
- Deployment: Hardware-agnostic operation, with Windows 11 LTSC licensing embedded and preinstalled. Named validated servers include Dell PowerEdge R6725/R670 and HPE ProLiant DL365 Gen11/DL360 Gen12.
- Maintenance: Faster patch installation that avoids unnecessary reboots in most cases.
- Privilege management: Temporary Active Directory or local-group elevation scoped to particular assets, plus ESXi account discovery.
- Security: TLS 1.3, selectable cipher suites and a configurable certificate-authentication hostname for clients lacking TLS 1.3 post-handshake authentication.
- Windows access: Entra ID directory accounts for RDP policies, with passwords and TOTP MFA managed by SPP.
“Hardware-agnostic” is not a blank cheque for arbitrary servers: the same documentation points administrators toward compatibility and configuration requirements. Nor does avoiding unnecessary reboots mean every patch is reboot-free. Those qualifications belong in deployment planning, not in the footnotes after a maintenance window goes sideways.
For SPS, the CyberNewswire announcement says version 9.0 moves to Ubuntu 24.04 LTS and removes the need for a separate license file simply to continue operating. These remain vendor-attributed claims here; removing a license-file requirement should not be interpreted as eliminating commercial licensing obligations.
The practical Windows finding: test your automation
One useful detail outside the announcement concerns PowerShell compatibility with SPP’s TLS changes.
One Identity’s maintained safeguard-ps documentation says the module connects to SPP 9.0 from both Windows PowerShell 5.1 and PowerShell 7 without additional flags. However, successful connectivity does not establish that TLS 1.3 was negotiated: the client runtime and underlying operating-system TLS provider still matter.
There is also a consequential distinction for administrators enforcing protocol policy:
- In PowerShell 7, the module applies TLS constraints per request.
- In Windows PowerShell 5.1, those settings change
ServicePointManager.SecurityProtocolprocess-wide, potentially affecting other HTTPS calls in the same session. - One Identity recommends PowerShell 7.3 or newer when TLS 1.3 enforcement is required.
The practical takeaway is to validate existing scripts under their actual production runtime—not merely confirm that someone can sign in through a browser.
What administrators should validate
A sensible evaluation should focus on three outcomes:
- Deployment remains supported. Match the intended hardware and configuration to One Identity’s requirements rather than relying on the hardware-agnostic label.
- Temporary privilege is genuinely temporary. In a pilot, verify that the intended asset receives the requested group elevation and that access is removed afterward.
- Security policy preserves required access. Test certificate-authenticated clients and automation before tightening TLS settings. The documented certificate-authentication accommodation makes this a compatibility exercise, not just a cipher-selection exercise.
Safeguard 9.0’s strongest proposition is operational: make privileged access easier to deploy and maintain while narrowing how elevation is granted. The release notes establish concrete mechanisms; they do not establish quantified savings or universal compatibility. For enterprise teams, the right next step is a scoped pilot with clear success criteria—not an assumption that a simpler product description guarantees a simpler migration.