> Indeed, no drivers for Windows on ARM for now.
@Aziz BRIGUI
Just checked with the Microsoft's AI, and it says so [edited] :
* You don’t need to rewrite your WinUSB‑based driver—you only need to update your INF so that Windows on ARM64 can match and install it.
Add ARM64 INF decorations (e.g., .NTarm64 or .NTarm64.10.0) to your INF file and ensure your catalog (.cat) is regenerated and signed for ARM64.
Windows requires architecture‑specific INF sections.
To support ARM64, add NTarm64:
[Manufacturer]
%MfgName% = DeviceList, NTamd64, NTarm64
Then add a matching install section:
[DeviceList.NTarm64]
%DeviceName% = WINUSB_Install, USB\VID_xxxx&PID_yyyy
* Regenerate and sign the .cat file.
You do need to sign your driver package for Windows on ARM, but you do NOT need an EV certificate or a Microsoft developer account unless you want automatic Windows Update distribution. For most INF‑only WinUSB packages, the signing requirements are simpler than people expect.
You only need:
A standard code‑signing certificate (non‑EV)
Issued by any trusted CA (DigiCert, GlobalSign, Sectigo, etc.)
Used to sign the catalog (.cat) file
Works on Windows 10/11 x64 and ARM64
This is the same process you already use for x64:
inf2cat /driver:.\ /os:10_ARM64,10_X64
signtool sign /fd SHA256 /a /v /tr http://timestamp.acs.microsoft.com /td SHA256 MyDriver.cat
/os:10_ARM64 is exactly what you should use, and it does cover Windows 11 ARM64.
The timestamp is optional, but you absolutely want to.
----
TL;DR if a user happens to have a standard code‑signing certificate, they can fix and re-sign the ST-Link INF & cat files by themselves. The INF files can be found in CubeProgrammer installation.
Also, recent versions of Zadig (libwdi installer) support installation of user-provided INF files. Give it the st-link INFs.
