Catalog files do not remove hash management, they move it

There is a moment in most App Control programmes where someone opens the policy, sees a long list of hash rules, and asks whether catalog files would tidy it up.

They would. The policy gets shorter and the hashes move somewhere else. The question worth asking first is whether anything actually got easier, and usually it did not.

What a catalog actually is #

A catalog file is a signed container of file hashes. The signature is detached from the files, so a file whose hash appears in a signed catalog inherits that signature and satisfies a signer rule.

That is genuinely useful for one problem: giving unsigned software a signature without modifying the binaries. If a vendor ships unsigned and you cannot get them to change, a catalog lets you treat that software as signed by you.

What it is not is a way to stop managing hashes.

Catalogs do not solve hash churn #

A catalog identifies files by exact hash, which means it has the same property that made the hash rules look untidy in the first place. Change a binary and its entry no longer matches. Microsoft is direct about this: because catalogs identify files by hash, any change to a file can invalidate the signature, and an updated catalog signature is required when application binaries change.

So the vendor ships an update and you regenerate the catalog, resign it, redeploy it, and work out whether the previous one can go.

The churn did not reduce. It moved from a policy you can read into an artefact you have to distribute.

Why the operations get harder, not easier #

A hash rule in a policy is a visible object. You can attach an application to it, an owner, an approval, a reason, a scope and a review date. When you want to know why a binary is trusted, you look at the rule.

A hash inside a catalog is none of those things. To manage it you have to know which catalog contains it, which version of which application that catalog belongs to, which endpoints currently have it, whether anything still needs it, and whether removing it breaks something.

The policy will not tell you. All the policy says is that the catalog signing certificate is trusted. The file level decisions sit outside it.

That is the trade in one sentence. The policy got shorter and the trust decisions got less visible.

Cleanup is where it hurts #

Retiring an obsolete hash rule is a small piece of work. It has an owner, telemetry shows nothing has used it, and it comes out of the policy.

Retiring a hash inside a catalog is a different kind of task.

The obsolete hash sits alongside many others in the same file. That catalog may cover install, repair, rollback and uninstall paths for the application, so a hash that looks unused during normal running may still be needed the next time somebody repairs it. The catalog may be present on some endpoints and not others, depending on when each was built. Removing it can break the devices that still depend on it.

None of that is visible from the policy, so cleanup becomes a discovery exercise across the fleet rather than an edit with a known blast radius. In practice that means it does not happen, and the estate accumulates signed catalogs nobody is willing to remove.

The distinction that settles it #

Catalogs solve a signing gap. Governance solves a lifecycle gap. These are different problems and they get conflated because both of them touch hashes.

If the difficulty is that a file is unsigned and needs to be allowed, that is a hash rule with an owner and a review date.

If the difficulty is that a file genuinely has to behave as though it carries a detached enterprise signature, that is a catalog.

The mistake is reaching for a catalog to fix untidiness, because untidiness is a governance problem and a catalog does not govern anything. It relocates.

Where each rule type belongs #

Hash is the most specific rule level and the most maintenance, which is why it should be the last resort rather than the first. Choosing App Control rule levels covers the full set and what each costs. In short:

• Sign what you build. Embedded signing on your own applications removes the problem rather than managing it.
• Publisher or file publisher rules for signed vendor software, because they survive updates where a hash does not.
• Signed version rules where you need a floor on the version as well as the publisher.
• Hash rules for unsigned files and for exact binary control, where every change genuinely should trigger a review.
• Catalogs for the specific cases above, and not as a tidying exercise.

Microsoft's own guidance points the same way, recommending that code signing be part of application acceptance criteria where possible. That makes it a procurement question as much as a technical one, which who application control involves covers.

When hash rules are the right answer #

Deterministic control is the case for them, and it is a real case.

Unsigned utilities. High risk tooling. Temporary exceptions with an expiry. Binaries that change rarely. Break glass tools. Anything where a change to the file should force somebody to look at it again.

In all of those, the exactness that makes hash rules high maintenance is the feature. You want the rule to break when the file changes.

Many files is not the argument it sounds like #

The strongest sounding case for catalogs is an application with a large number of static files, where the rule count would be significant.

It is weaker than it sounds. The rule count grows, but the rules stay grouped under one application, with one owner and one approval. What you gain from a catalog is a shorter policy file. What you give up is knowing, without an investigation, what is trusted and why.

A shorter file is not the goal. A trust decision somebody can defend is.

Where PoliEze fits #

This is the difference PoliEze makes to the decision, and it changes the answer.

Without a control plane, a long list of hash rules really is unmanageable, and a catalog can look like the lesser evil. With one, each hash rule is a governed object rather than a line in an XML file: it has the application it belongs to, an owner, the approval and the reason behind it, the scope it applies to, a review date, and usage evidence showing whether it is still needed.

That last one is what makes retirement possible. The reason catalogs accumulate is that nobody can prove a hash is unused. When usage is visible, removing a rule is a decision rather than a risk.

So the position is straightforward. Catalogs hide hash complexity. A control plane governs it. Given the second, the first stops being worth its operating cost, and should be kept for the cases where detached signing is genuinely the requirement. The platform sets out where policy lifecycle management sits in the sequence.