Running my security product as a PPL, obtaining an Altitude value

Question

Hi,

I'm developing a security product that needs to access ETW classes that require an altitude value, and needs to run as a Protected Process Light (PPL).

What do I need to do to have this? I'm already a Microsoft Partner and part of the HW program so I can sign drivers.

Thank you!

Answer 1

Hi @Tomer Filiba ,

Thanks for reaching out!

From my research, the two things you mentioned are controlled by Windows and can’t be enabled simply by writing code or signing a driver.

For altitude values, these are assigned by Microsoft to ensure that security and filter components load in a consistent order and don’t conflict with each other. Developers cannot generate or choose an altitude themselves.

Microsoft documents how altitude assignment works here:

• https://learn.microsoft.com/windows-hardware/drivers/ifs/minifilter-altitude-request

That documentation explains the official process for requesting an altitude.

---

For Protected Process Light (PPL), the requirement is tied to how Windows trusts and signs the binaries. Even if you are part of the Hardware Developer Program and can sign drivers, that alone does not automatically allow a process to run as PPL. Windows only enables PPL when the executable is signed in a way that the operating system recognizes for protected services.

Because of that, there isn’t a configuration switch or public checklist that enables PPL directly. In practice, developers usually need to work with Microsoft (for example through their partner contact or support channels) to explain the product scenario and understand whether the required signing and trust level can be provided.

---

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance provide feedback. Thank you!

Answer 2

To obtain both a minifilter altitude and the ability to run components as Protected Process Light (PPL), two separate tracks are involved: filter altitude allocation and appropriate signing/protection for your security binaries.

1. Requesting a minifilter altitude

For ETW classes or file-system/registry minifilters that require an altitude, a filter altitude must be requested from Microsoft. The process is:

1. Send an ASCII text email to fsfcomm@microsoft.com with subject Filter altitude request.
2. Include all required fields in the body; missing information can delay assignment. The required fields are:
   • Company name
   • Contact e-mail (long‑term company alias, not an individual; the allocated altitude will be sent here)
   • Product name
   • Product URL
   • Product/Filter description (one paragraph to help Microsoft determine the appropriate altitude)
   • Filter filename
   • Filter type: Registry, FileSystem, or Both
   • Filter start-type: Boot, System, Auto, or Demand
   • Requested filter load order group (see “Load order groups and altitudes” in the referenced documentation)
   • Requested altitude (within the appropriate load order group; Microsoft may assign a different value based on availability and functionality)
   • Additional information (anything else Microsoft should consider when assigning the altitude)
3. Allow up to 30 business days for processing. There is no alternative/expedited mechanism outside this process.
4. Once assigned, the altitude will eventually appear in the public “Allocated filter altitudes” table (updated 1–2 times per year).
5. If an integer altitude has already been issued for the product type/load‑order group, fractional altitudes can be created under that integer altitude for additional filters in the same group.
6. Running security components as Protected Process Light (PPL)

For a security/anti‑malware service that needs to run as PPL and launch protected child processes:

1. Use the extended attribute key PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL with the UpdateProcThreadAttribute API when creating the child process.
2. Pass a pointer to the attribute value PROTECTION_LEVEL_SAME into UpdateProcThreadAttribute.
3. In the CreateProcess call for the child process, specify the CREATE_PROTECTED_PROCESS flag in the process creation flags parameter.
4. Ensure the service binaries are signed correctly:
   • Sign using the /ac switch so the signature chains through a cross‑certificate to a known CA.
   • A self‑signed certificate without proper chaining to a known root CA will not work for protected processes.
5. Driver signing options relevant to security products

Since participation in the Hardware Program and driver signing capability already exists, choose signing based on scenario:

• For testing scenarios (not retail distribution), attestation signing can be used:
  • Meet the prerequisites for attestation signing (EV code signing certificate, registration in the Hardware Developer program, etc.).
  • Submit drivers through the Windows Hardware Compatibility Program (WHCP) attestation path as described in the attestation signing documentation.
• For full release and Windows Update distribution, follow WHCP/HLK certification and submit via the Windows Hardware Developer Center Dashboard.

Note that attestation‑signed drivers for retail audiences are no longer published via Windows Update; they are supported for specific testing scenarios only.

---

References:

• Request a filter altitude identifier
• Protecting anti-malware services
• IHV Attested Signing Service
• Attestation sign Windows drivers
• Driver Signing Policy
• Driver security checklist