Is the durable Artifact Signing vendor EKU (1.3.6.1.4.1.311.97.*) accepted as an identity anchor for LSA plug-in signing, as it is for the Antimalware signer?

We are preparing a submission to the Partner Center File Signing Service for an LSA plug-in, and we would like to understand one point before enrolling.

The LSA signing requirements state that "the CAB file signature must match the EV code signing certificate for your organization" — that is, the requester's identity is anchored to a pinned, long-lived certificate.

Azure Artifact Signing, by design, cannot satisfy that: it rotates certificates daily with short validity and never exports them. Instead it anchors vendor identity to a durable EKU with the prefix 1.3.6.1.4.1.311.97.*. Microsoft already relies on that mechanism for user-mode anti-malware binaries running as PPL-Antimalware, where the vendor embeds its unique Artifact Signing EKU identity in the ELAM driver resource file info.

So the two models exist side by side: certificate-pinned identity for the Lsa signer, durable-EKU identity for the Antimalware signer.

There is a further reason the answer is not obvious to us. The Artifact Signing FAQ states that "signing with the Partner Center is kernel-mode signing… sign your user-mode binaries by using Artifact Signing". An LSA plug-in is a user-mode binary — it is loaded by lsass.exe — yet the file signing requirements route it to Partner Center and to a pinned EV certificate. So the user-mode / kernel-mode split does not by itself explain why the Lsa signer is outside the durable-EKU model.

My question is not whether Artifact Signing is accepted for LSA submissions today — I understand it is not, and I understand why a daily-rotating certificate cannot be pinned. My question is whether the durable-EKU anchoring model is available, or planned, for the Lsa signer as well — or whether there is a design reason it is deliberately restricted to Antimalware.

I am aware of the existing thread "Hardware Program Verification using Azure's Trusted Signing (instead of EV Code Signing Certificate)" (https://learn.microsoft.com/en-us/answers/questions/5866910/) and of the answer given there, namely that an EV code signing certificate still has to be purchased. That thread is about program registration and drivers, and it never mentions the EKU mechanism — so I do not think it answers the question above.

References:

LSA Plugin or UEFI Firmware Signing Requirements — https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/file-signing-reqs

Artifact Signing certificate management (durable identity EKU) — https://learn.microsoft.com/en-us/azure/artifact-signing/concept-certificate-management

Protecting anti-malware services (ELAM resource file info, EKU field) — https://learn.microsoft.com/en-us/windows/win32/services/protecting-anti-malware-services-

• Artifact Signing FAQ (ELAM EKU guidance; "Partner Center is kernel-mode signing") — https://learn.microsoft.com/en-us/azure/artifact-signing/faq

Also asked in Italian here: https://learn.microsoft.com/it-it/answers/questions/5984755/leku-durevole-di-artifact-signing-1-3-6-1-4-1-311 — reposted in English under the WDK tag to reach the audience that owns the File Signing Service. Same question, not a duplicate.