Code signing audio plugins in 2025, a round-up

One of the last pain points before launching an audio plugin business is dealing with code signing.

The ecosystem has changed over the years, especially on Windows, so here's a 2025 roundup.

Short Summary

Not much has changed on macOS. Code signing and notarization is still first-party, handled through Apple. Your programs won't run on other machines without notarization. The cost is $99/year, requires signing up for the Apple Developer Program.

Windows became much more accessible in 2024 and 2025. Azure Trusted Signing is now available for $9.99 a month — with the caveat that you are signing up as a business which is older than 3 years or as an individual. Otherwise you can go the manual cert path.

Code Signing Jargon

• Code Sign. Attaching a cryptographic signature to a binary to declare you created the software and it hasn't been tampered with.
• Windows Defender Antivirus. A Windows feature that scans .exe and .dll binaries for malware.
• Windows Defender SmartScreen. A Windows security feature that blocks untrusted or potentially harmful applications and websites by checking files against Microsoft's reputation database. Untrusted software throws a warning.
• macOS Gatekeeper. Apple's security feature that verifies downloaded apps to ensure they come from identified developers and haven't been tampered with. Untrusted software is blocked by default.
• Notarization. On macOS, you upload your software to register it with Gatekeeper, and it does a server side scan to confirm it's code signed and malware free.
• Staple. On macOS, you can bundle proof of notarization with the binary, allowing Gatekeeper to perform offline verification.
• Continuous Integration (CI). Using dedicated hardware or cloud services like GitHub Actions to build and test your products.
• KMS. Key Management Service. A place to deploy and securely store Windows code signing certificates. You can use AWS or Azure Key Vault.
• OV cert. Organization Validation certificate. Provides some level of trust, but SmartScreen will still display a warning until enough "reputation" is built (couple dozen to hundred users per unique binary).
• EV cert. Extended Validation. Requires stricter identity validation, provides higher level of trust. In some cases, still requires some reputation to be built to bypass SmartScreen.
• Azure Trusted Signing. Microsoft's new service that lets you avoid manually buying and deploying certificates. Instant reputation and bye bye SmartScreen.
• WrapTool. PACE's special wrapper tool for signing ProTools' AAX format.

Do I need to code sign on macOS?

If you want others to use your software, the answer is a resounding yes (even if you aren't selling your plugin quite yet).

Without signing, software will not run on other apple computers. If you hand someone a freshly built VST3 from your computer, they will be presented with this screen:

You could then tell people to manually go into Privacy & Security to whitelist your software, clicking Allow.

This gets hairy fast. Sometimes the approval doesn't "take," especially if you have more than one binary or are distributing a dylib or two. Note that the user will have to do this same dance each and every time they get an updated version of the software.

But probably the best argument is it's helpful to your friends and beta testers, especially if they are already donating their valuable time. It's better to pay $99 and a few hours of your time than deal with hours of hand-holding users, asking them to jump through hoops.

Do I need to code sign on Windows?

Windows is a bit more forgiving.

Unsigned executable installers display a warning:

The user then has to click More Info and then Run Anyway to proceed. This can feel a bit scary for users.

I know devs who just tell their users "Don't worry, just click past the SmartScreen warning." It hasn't stopped them from making a living. But now that Microsoft's Azure option showed up, most of them have hopped on board the code signing train.

Additionally, you'll still want to codesign your executables so Microsoft Defender doesn't accidentally identify them as malware.

How to code sign on macOS

Read my full write up on macOS code signing in CI.

This is relatively straightforward. Nothing has changed on macOS since 2022 when notarytool was introduced, making notarization more straightforward, especially in CI.

The flow basically looks like this:

• Pay $99 to get an Apple Dev Account.
• If you are enrolling as a business (vs. individual) you will need to get your D-U-N-S number, which also can take a few days.
• Wait 1-2 days for Apple to approve.
• Export signing certs from Xcode.
• Start signing executables and installers.

There's some subtlety around which certs to export (installers need a different cert than binaries) But that's usually the only place people go wrong.

There are a couple of high level "gotchas" with macOS notarization.

• Anytime Apple releases a new developer agreement, you will need to log in and "sign" (check the box) in order to continue notarizing.
• Apple certificates do expire in one year. You can see in Xcode when the dates are. Protip: add to your calendar so you aren't surprised when trying to cut a time sensitive release.

How to code sign on Windows

There are currently 3 options on Windows.

• Buying an OV or EV cert from a third-party, storing it on a special usb dongle and signing only from one machine.
• Buying an OV or EV cert from a third-party, and deploying it to a KMS, such as AWS, Azure KMS.
• Going with Azure Trusted Signing as a business with 3 years of history. Note, as of April 2025, this is restricted to Canada or the US until this Microsoft service goes General Availability.

There are some BIG benefits to using Azure's new Trusted Signing service:

• Cheaper. $9.99 a month vs. certificates that can cost $200-300 a year.
• With luck, it's extremely fast to verify your identity (under 15 minutes).
• Great tooling, easy to setup in Continuous Integration (CI)
• You get instant reputation. This is huge. Gone are the days of needing to build reputation on a third-party cert (Even EV certs required this).

In my opinion, the only reason to not use Azure Trusted Signing in 2025 is if your business is less than 3 years old and you don't want to sign up as an individual (your personal information gets placed in the cert).

Here are some resources to get you started on Windows:

• Signing Windows binaries using AWS KMS (written by Tobias from Moonbase)
• How to code sign Windows installers via Azure KMS on GitHub Actions (written by Sudara)
• Code signing on Windows with Azure Trusted Signing (written by Sudara)

Code signing AAX plugins in 2025

I've written multiple code signing articles, so I often get asked about Avid's proprietary AAX format used by ProTools. I don't currently ship AAX, but I have helped a lot of devs through their process.

First, some key facts about signing AAX:

• The AAX SDK is now distributed as a part of JUCE 8, making it easy to get started building for the format.
• AAX requires a hardware iLok dongle for signing. (If you ever go to ADC, you can pick one up for free, otherwise you must purchase one and have it physically delivered).
• It also requires special signing software called Eden, which has things like WrapTool which wraps Microsoft's signtool command on Windows.
• Because the PACE tooling wraps the Windows tooling, you still need to setup normal code signing on Windows with one of the methods described in the last section. This is to provide OS-level trust on the binaries and pass SmartScreen. The PACE signatures prove you are an registered/approved Avid developer.

The hardware iLok requirement may throw a wrench into your existing Continuous Integration setup — by default you'll need physical access to the signing machines. There are currently three CI solutions to pick from:

1. Sign up and pay for PACE's cloud signing. This is an enterprise product. A brand new indie dev might not be able to justify the yearly price, but it shouldn't break the bank if you expect a lot of ProTools users.
2. Use "local" or "self-hosted" or "self-managed" CI runners for your cloud CI. You can still use cloud CI services from GitHub or GitLab, but you plug the iLok into your local machines and install PACE's software there. You can read Pamplejuce's (my JUCE CI template) manual for more details on setting that up on GitHub.
3. Set up CI completely locally with software like Jenkins.

To get started signing AAX:

• Sign up as an AAX Developer if you haven't already.
• Request a Pro Tools Developer Bundle activation code by sending an email to devauth at avid dot com.
• They'll instruct you on next steps, including purchasing an iLok or offering yearly pricing for Cloud Signing.

AAX in conjunction with Windows cloud signing services

After Azure Trusted Signing came out in 2024, Koaladsp wrote a great Azure guide which included how to "wrap" PACE's signing tools to code sign executables while using a cloud service for your OS-level trust certificate.

As of 2025, PACE's Eden 5.10 is out and you no longer need to do the wrapping, you can pass in the needed options for Azure/your cloud KMS via --explicitsigningoptions.

Testing and troubleshooting

Building in CI has the advantage that your normal development machines can always be used to test that code signing works.

If you build locally, hand the installers to friends to make sure they open. Pretty easy!

For Azure troubleshooting help, there are lots of devs giving tips on my article as well as on the JUCE forum.

I also have a list of macOS notarization and troubleshooting tips on my macOS article.

Good luck shipping! 🚢