Cat On A Spreadsheet

At this point in the series, you have something that already looks very different from a typical Excel solution. Your automation lives inside a structured .xlam add-in. Your source code is exported to text files and managed in Git. From a development perspective, this is already a major step forward.

However, the moment you try to use this add-in in a more controlled environment — or share it with someone else — you will likely run into a hard stop. Excel refuses to run the macros, or displays warnings that undermine user trust. This is not a bug. It is Excel doing exactly what it is designed to do.

Modern Excel environments treat macros as potentially unsafe unless they come from a trusted source. If you want your add-in to behave like a professional, distributable tool, you need to establish that trust explicitly. This is where digital signing comes in.

What Digital Signing Actually Does

Digital signing is often misunderstood as a form of encryption or protection. It is neither.

A digital signature does not hide your code and it does not prevent someone from reading it. Instead, it provides two guarantees. The first is identity: the signature tells Excel who signed the code. The second is integrity: if the code changes after it has been signed, the signature becomes invalid, and this is critical because it means that once you sign your add-in, any modification — even a single character — breaks the signature. Excel can then warn the user that the file has been altered since it was approved.

In practical terms, a digital signature allows Excel to answer the question: “Can I trust that this code came from a known source and has not been tampered with?”

Development vs Distribution Certificates

Not all certificates are equal. When you are developing locally, you do not need a certificate issued by a central authority. A self-signed certificate is sufficient. It allows you to sign your code and configure your own machine to trust it.

In a wider environment, especially inside a company, things are different. Trust is usually managed centrally. Certificates may be issued by an internal certificate authority, and users’ machines are configured to trust those certificates automatically.

For now, we will focus on the developer workflow using a self-signed certificate. This is enough to understand the process and build a working setup.

Creating a Self-Signed Certificate

Excel ships with a small utility specifically for this purpose. Search your system for:

This tool allows you to create a personal code-signing certificate. Run it and provide a name, for example:

Once created, this certificate is stored in your user profile and becomes available for signing VBA projects. This certificate is only trusted on your machine unless explicitly exported and installed elsewhere.

Signing the Add-In

With the certificate created, you can now sign your add-in. To do that, open your .xlam in the VBA editor and navigate to:

Click Choose, select your certificate, and confirm. Save the project. At this point, your add-in is digitally signed.

This is a good moment to understand an important rule. The signature is tied to the exact state of the code at the moment of signing. Any subsequent change invalidates it. This has a direct impact on how you structure your workflow.

What Happens When the Code Changes

After signing, make a small change to your code and save the project. If you return to the Digital Signature dialog, you will see that the signature has been removed. Excel does this automatically because the integrity guarantee is no longer valid.

This behaviour forces discipline. You cannot casually edit a signed production add-in. Any change requires re-signing, which effectively creates a new trusted version. This is exactly what you want in a controlled deployment model.

Trusting the Certificate

Signing alone is not enough. Excel must also trust the certificate.

The first time you open a signed add-in, Excel will display a security warning. It will show the publisher name associated with the certificate and you have the option to trust this publisher. Once trusted, Excel will allow any code signed with that certificate to run without prompting.

This creates a clean experience for users. Instead of repeated warnings, they see a consistent and trusted automation tool.

Trusted Publishers vs Trusted Locations

There are two common ways to allow macros to run without warnings.

Trusted locations allow any file in a specific folder to run. This is simple but broad. Anything placed in that folder is implicitly trusted, which can be risky.

Digital signing, on the other hand, is precise. Only code signed with a trusted certificate is allowed to run, regardless of where the file is stored. For controlled distribution, signing is the more robust approach. It scales better and aligns with enterprise security practices.

Integrating Signing Into Your Workflow

At this stage, your workflow should start to take shape. During development, you modify code freely inside the add-in. You export modules to Git and iterate as needed. When you are ready to produce a release version, you perform a clean build, ensure the correct code is loaded, and then sign the add-in. That signed file becomes the version you distribute.

This separation between development and release is subtle but important. It prevents accidental modification of deployed code and ensures that every distributed version is intentional.

Why This Step Matters

Without digital signing, your add-in will always feel like an unofficial tool. Users will see warnings, hesitate to enable macros, or work around security controls in ways that create risk. With signing, your add-in starts to behave like a managed application. It carries identity. It communicates trust. It integrates with Excel’s security model instead of fighting it. Combined with version control and a structured add-in architecture, this moves your project firmly into the territory of professional software.

The Next Step

At this point, you have:

• a structured .xlam add-in

• version-controlled source code

• a signing process that establishes trust

The final step is to make this add-in available to others in a controlled and maintainable way. In the next article, we will move from local development to centralized distribution, placing the add-in in a shared location, managing updates, and ensuring that users always run the correct version without manual intervention.

This is where the project becomes not just a tool, but a platform.

Full Service Consulting

Reporting

Automation

Cat On A Spreadsheet