Vulnerability management on an Acumatica instance is a different exercise from a typical web application because the attack surface is split cleanly into two categories with almost nothing in common: platform vulnerabilities (Acumatica core, IIS, .NET Framework, SQL Server, the OS) that get patched by upgrade or by your ops team, and dependency vulnerabilities inside the customization layer - the NuGet packages and third-party libraries your custom code actually references. Clients regularly manage the first well and completely ignore the second.
Platform-side vulnerability tracking is mostly a cadence problem
Acumatica ships security patches and version updates on a predictable release cadence, and staying reasonably current is the single highest-leverage thing a client can do here - most platform CVEs I've seen disclosed affect versions two or three releases behind current, not the latest. The practical obstacle is never technical; it's that clients delay upgrades because a heavily customized instance makes every upgrade feel risky. That's a real tradeoff, but the risk calculus should explicitly weigh "known vulnerability in an old version" against "upgrade regression risk," not default to never upgrading because upgrades are annoying.
The customization layer has its own dependency tree, and it goes stale silently
Every custom class library referencing NuGet packages for its own logic - a PDF generation library, a JSON parser beyond what's built in, an HTTP client wrapper - carries whatever vulnerabilities exist in that package's version, completely independent of Acumatica's own patch cadence. Nobody automatically bumps these; they sit at whatever version was current when the customization was written, sometimes years earlier. I run a dependency audit against every client's customization solution now as a standard part of any security engagement, because it's the check almost nobody else runs on Acumatica projects specifically.
# Against each customization project's packages.config / .csproj
dotnet list package --vulnerable --include-transitive
# Or, for older packages.config-style projects without SDK-style csproj,
# a NuGet vulnerability scan against the same package list
On one audit this turned up a five-year-old version of a JSON library with a known deserialization vulnerability, referenced by a customization that hadn't been touched since it shipped - nobody had thought to check because "it's just a NuGet package, not really part of the security surface" was the unstated assumption.
Not every CVE against a referenced package matters equally
A vulnerability scan against your dependency tree will surface far more findings than are worth acting on immediately. I prioritize by actual reachability: is the vulnerable code path in the package something your customization's code actually calls, or is it a feature of the library you never use? A deserialization vulnerability in a JSON library's XML-adjacent feature you never invoke is a much lower priority than the same severity rating against a code path your integration calls on every request. Generic CVSS scores don't know your usage pattern; you do.
A vulnerability three levels deep in a transitive dependency of a package you deliberately chose is easy to miss with a manual review and is exactly what automated scanning catches. Don't rely on eyeballing your own packages.config - run the actual tooling, because the direct references are rarely where the real exposure sits.
A cadence that actually gets followed, not an aspirational one
What works in practice: platform patch review monthly (checking Acumatica's release notes and CVE disclosures against your current version), dependency scanning of customization projects quarterly or on every new customization's initial commit, and a lightweight annual pen test for instances handling anything regulated. A vulnerability management process too heavy to actually follow produces worse security than a lighter one that reliably runs, and I've seen more instances harmed by an abandoned quarterly-scan policy than by never having had one.
Wrapping up
Treat Acumatica vulnerability management as two separate tracks: platform patching, which is a discipline problem solved by staying current on a predictable cadence, and dependency scanning of the customization layer, which almost nobody does by default and which is where I've personally found the most concerning findings. Prioritize by whether your code actually exercises the vulnerable path, not by CVSS score alone, and pick a cadence realistic enough that it survives contact with a busy project schedule.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.