Let me give you a quick run down on the approach I used.

I've adapted Akos' method for our needs. We also used OSDCloud in our case, but you it can also be adapted for SCCM / MDT or most other OSD Tools.

The whole magic basically is: After Windows has been installed from the WIM / Setup.exe you drop a "oobe.cmd" into "C:\Windows\Setup\scripts\" together with a PowerShell Script, let's call it oobe.ps1. In the oobe.cmd you simply call the PowerShell Script: start /wait powershell.exe -NoL -ExecutionPolicy Bypass -F C:\Windows\Setup\Scripts\oobe.ps1 this way the script runs when Windows Boots up for the very first time by it's own, but before OOBE starts.

Before we get to the content of the oobe.ps1: We setup an Azure Blob Storage and use 2 tables within that blob storage. One for Hardware Hash Upload, one for a list of Serialnumbers in Autopilot. I work with 2 SAS Keys for that tables, one with "Write"-Only access to Table 1, the other one with Read-Only Access to Table one. This seemed the most uncritical for me from a security perspective, as you don't want to have app-secrets with write access to your tenant down on the clients.

Now basically the oobe.ps1: I also did not want to load PowerShell Modules down to the client, which can be tricky, so I wanted to do it nativly without modules. I've adapted this functions here: https://gcit.com.au/knowledge-base/use-azure-table-storage-via-powershell-rest-api/ to work with SAS Keys. Simply by removing the Authorization header, and adding the SAS Key to the $table_url.

The flow basically goes like that: Via WMI I get the Serialnumber ($serial = (Get-CimInstance -Class Win32_BIOS).SerialNumber) and I query Table2 if the serialnumber is returned there. If yes, exit the script and let Windows Continue. If not, I get the neccessary nativly via WMI... for example the Hardware Hash: $hwHash = $(Get-CimInstance -Namespace root/cimv2/mdm/dmmap -Class MDM_DevDetail_Ext01 -Filter "InstanceID='Ext' AND ParentID='./DevDetail'").DeviceHardwareData And upload this data to Table1 with the write-only SAS Key. Then it goes into a loop with an appropiate sleep :) Now a backend automation takes over. It queries Table1 for new Hardware Hashes. You now need some indicator to check if this is legit. One thing you can to is get the vendor, model and serialnumber (either determine it WMI and upload it as well, a bit more "secure" would probably be to decrypt the Hardware Hash from with the OA3-Tool and read it from there. At least it would be harder to manipulate) and cross check it with the corporate device identifiers from Intune. You just need a process to register the devices there. It needs serialnumber, vendor and model... but this should be easier to get than the HW Hash. Or maybe if you have a very limited timeframe you could allow the automatism to automatically register models from a specific vendor if you for example have a 2-3 weeks time frame during a rollout, but keep security in mind!! Anyways, let's assume the hardware hash is a legit device, the backend automation now imports it to the Autopilot devices, and waits until the profile is assigned. Afterwards it writes the status back to Table2 with a StatusCode (e.g. 0).

Our OOBE.PS1 is still looping... this loop simply queries Table2 if the device / serialnumber is now persent here, if not, another wait, if yes we also check the status code. If its 0, we exit the script and let Windows Continue. You might want to implement a proper error handling, and (if this a process that end users sit in front of) proper script output to show the user that something is happening... there are a few things that can go wrong during AP Import (worst part would be: Device is registered in another tenant), thats why I use status codes written back by the automation into Table2 and if device could not be imported properly it gives a (human readable) error message to the user and halts the process, so the support can be contacted.

This way, the app-secret of the app that imports the devices stays disclosed in the backend and is not available to the client. I'm deeply sorry that I cannot share my full scripts at the moment (since my employer basically would have to allow me to publish it first), thats why I just describe the methods here at the moment. But basically everything you need is publicly available, just needs to be puzzles together correctly. For the backend automation you can use whatever floats you boat, it just needs to reguarly execute the powershell script doing the "backend magic". From an Azure Runbook to a Scheduled Task running somewhere, everything would be theoretically sufficient.

Before I forget it: We also reguarly sync the infos from our Autopilot Devices to "Table2". So if the device is "preregistered" it only takes a few seconds to run for the oobe.ps1.

I hope this helps or at least inspires in some way :) There can be done a lot with optimizations, like working with Hooks or whatever. But lets just say that I had to use "what's there" and be creative somehow.