This blog reveals how a silent HP OneAgent update (version 1.2.50.9581) deleted the MS-Organization-Access certificate, causing devices to disconnect from Entra ID. And yes, it’s as bad as it sounds
Introduction
It all started with a subset of users reporting that they were unable to log in.
After a reboot, their Windows 11 devices only showed the local LAPS account on the sign-in screen.
As shown above, there was no option to use their Microsoft Entra credentials. After fetching the LAPS password and logging in, we checked the device registration status with dsregcmd /status. The outcome was the same on every single one:
The devices were no longer Entra joined.
The whole Entra/Azure AD Join was gone! With it, the devices had silently fallen out of the cloud. The whole trust between Windows and Entra ID disappeared.
The First Clue: HP OneAgent
When comparing the affected systems, a pattern quickly stood out.
Only the HP Next Gen AI models were impacted, devices like the HP EliteBook X Flip G1i.
After spending some time finding out whether there were any changes or updates, one thing stood out! Every single one of them had recently received a new background update: HP OneAgent 1.2.50.9581. Normal HP devices without AI hardware were fine because they used a different version of the OneAgent.
Nothing else in the environment had changed.
No new policies, no Windows Updates, and no driver updates.
Something inside that HP OneAgent update had clearly gone wrong.
Digging Deeper into the HP OneAgent
We noticed that somehow the HP OneAgent installed a new version on its own and downloaded an additional SP161710 (SoftPaq). Thanks to Joël Ammann for providing that installer… that made it easier to understand what was going wrong)
The moment SP161710 was installed, the device lost its Entra join within a few seconds. So we extracted the SP to see what’s inside.
Opening the install.CMD file revealed its intent immediately:
REM Purpose: Completely removes HP 1E Performance Assist
That single line explained everything.
The package was designed to remove HP’s 1E Performance Assist component, a now-obsolete optimization tool. But instead of safely uninstalling one product, the script’s logic was written in a way that made it very dangerous. Almost as if AI had written that script.
The Broken Script
Scrolling through the install file revealed a block of PowerShell commands responsible for cleaning up leftover certificates.
The idea was simple: remove any 1E-related certificates used by the old Performance Assist service.
The implementation, however, was reckless. It deleted any certificate whose subject, issuer, or friendly name contained the substring “1E”.
That single condition was enough to cause serious damage.
The MS-Organization-Access certificate, the one that defines a device’s Entra relationship, could contain that exact 1e pattern in its subject.
So does the Microsoft Intune MDM Device CA certificate in some environments. The result? Both certificates were deleted within seconds, the moment that the install script is executed. The good news? There is 9,3% chance there is a 1e in the subject…
One thing is for sure: once the MS-Organization-Access certificate is removed, the Entra trust disappears like ice before the sun. The device is immediately unjoined from Entra ID. As I explained before on Call4Cloud, that certificate is the anchor, without it, the device has no proof of its cloud identity.
If only the MDM certificate had been removed, Intune would have recreated it automatically, as covered in Automatic Intune Certificate Recovery. But with the Entra certificate gone, there was no recovery.
The Entra join was dead.
What the Logs Revealed
The HP OneAgent logs confirmed exactly what happened: Install Component: job-hponeagent-update installed version: 1.2.50.9581 expected version: 1.2.50.9581
A few minutes later:
2025-10-22 10:15:26.457 INFO [hp-iot-device.dll] Http GET request to ‘ao8k1tq4n21z2-ats.iot.us-east-1.amazonaws.com/…/shadow?name=job-hponeagent-update’ completed with http code 200
That confirmed that the device wasn’t acting on its own.
The job came directly from HP’s cloud, specifically their AWS IoT control plane.
HP OneAgent checks in regularly with HP’s IoT backend to receive “shadow” updates.
Each shadow defines what should happen next on the device install, update, or remove.
In this case, the job-hponeagent-update shadow instructed the agent to download and execute a SoftPaq package. That package contained the faulty install.cmd cleanup script.
The worst thing that happened here? No ring-based deployments! The SP update seems to have been pushed to all devices all at once!
Looks like they didn’t learned from the CrowdStrike accident, and they just yeet it to prod. Before zooming in on how to fix it, let’s explore what that OneAgent is.
What HP OneAgent Actually Is
HP OneAgent isn’t just a telemetry client. It’s HP’s internal management service, part of the HP Application Enabling Software Driver.
Each HP device registers with HP’s AWS IoT Core under a unique identifier.
From there, HP can push “jobs” to the device.
Those jobs are executed locally by the OneAgent service running as SYSTEM.
Everything happens silently and outside Intune’s visibility.
That design allows HP to deliver driver fixes, firmware updates, or cleanup packages automatically even on Entra-joined and Intune-managed devices.
In this case, the same system that normally ensures maintenance, accidentally removed the certificates that define a device’s entire cloud identity.
HP Pulls the Faulty Update
After the issue was confirmed, HP quickly pulled back the affected SoftPaq linked to HP OneAgent 1.2.50.9581. The package that contained the broken cleanup script is no longer being distributed.
This prevents new devices from receiving the update, though any systems that are already installed will still require manual repair….yes manual repair
Option 1: Fixing the HP OneAgent Damage Locally
To bring the device back into Entra and Intune, you need to clean up the broken enrollments first, then manually rejoin.
Step 1 – Sign in with the local admin (LAPS) account
On the login screen, select the local admin or LAPS account, then sign in. (Yeah local admin account required.)
Step 2 – Run the cleanup script
Use this cleanup script to remove all stale Intune enrollment data and scheduled tasks.
That includes the registry paths under
HKLM:\SOFTWARE\Microsoft\Enrollments,
HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM,
and the EnterpriseMgmt tasks.
This ensures that the device no longer believes it’s already enrolled.
If you don’t clean up the old Intune enrollment registry keys and scheduled tasks, the join process will fail with the “This device is already enrolled” message and error 8018000a.
Step 3 – Rejoin the device to Entra ID
After running the cleanup script, open Settings → Accounts → Access work or school → Connect.
Sign in with the user’s Entra credentials.
The device will now re-register and re-enroll cleanly into both Entra ID and Intune.
Option 2: Fixing the HP OneAgent Damage Remotely
With the Entra certificate gone, performing a remote wipe will be difficult unless you also have Defender in place. How? Well… Defender comes with a nice additional feature called: Live Response.
Step 1: Activate MDE Live Response
Before we can use Live response, we need to manually enable this feature.
Step 2: Initiating the Live Response
Once you have enabled it, you could initiate a live response session to the device that has the issue
Step 3: Selecting the Remote Wipe script
The moment the live response connection has been established, you can upload a file to the library
Here is the script that will perform a remote wipe locally on the device
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_RemoteWipe"
$methodName = "doWipeMethod"
$session = New-CimSession
$params = New-Object Microsoft.Management.Infrastructure.CimMethodParametersCollection
$param = [Microsoft.Management.Infrastructure.CimMethodParameter]::Create("param", "", "String", "In")
$params.Add($param)
$instance = Get-CimInstance -Namespace $namespaceName -ClassName $className -Filter "ParentID='./Vendor/MSFT' and InstanceID='RemoteWipe'"
$session.InvokeMethod($namespaceName, $instance, $methodName, $params)Step 4: Executing the Wipe Script with Live Response
Once you select the proper script, you can kick it off pretty easily
With it, the device would initiate a local remote wipe and start rebuilding Windows. (of course,ensure your WinRe is active and you don’t have Dell devices with Raid enabled)
Please Note: I didn’t have the chance to test this on the broken device… so please do and leave us a comment
Why It Happened
The HP OneAgent update was legitimate. It came through HP’s trusted update channel.
Because it was signed and distributed by HP, Windows treated it as safe. The install.cmd script inside the package was simply written without guardrails. It assumed any certificate containing “1E” was safe to remove. That decision to nuke all certs from orbit broke the whole Entra join.
A single pattern match was enough to destroy the link between Windows and Entra ID across every affected device.
The Aftermath
The result was consistent on all HP AI models that received the update:
- Devices lost their Entra join instantly.
- Users could only log in with the local LAPS admin account.
It wasn’t a Microsoft update, a sync bug, or an Intune issue.
It was a trusted OEM agent executing a broken cleanup script.
Final Thoughts
HP OneAgent was designed to simplify updates and maintenance for modern HP devices.
But with version 1.2.50.9581, it crossed a line no one expected, it deleted the very certificate that defines a device’s identity in the cloud.
When the MS-Organization-Access certificate is gone, the Entra join is gone too.
And when that happens, the user isn’t just signed out.
The device loses its place in the organization entirely.
What started as a harmless cleanup turned into a quiet but complete disconnection from the cloud.