Acumatica Penetration Testing — A Complete Guide

Clients bring in outside penetration testers for their Acumatica instance fairly regularly now, usually driven by a customer's security questionnaire or an annual SOC 2 requirement. I've sat on the receiving end of several of these engagements as the developer who then has to fix whatever gets found, and the findings cluster into a small, predictable set that has almost nothing to do with Acumatica's own platform security and almost everything to do with how it was customized and configured on top.

What a competent tester actually targets on an Acumatica instance

A pen test against Acumatica rarely finds anything interesting in the base platform - it's a mature, widely deployed product and the obvious attack surface has been hardened over many release cycles. The interesting findings live in the custom layer: custom REST endpoints exposed through Business Events or custom actions, custom screens with permission gaps, and configuration issues like default admin credentials never rotated, or an SSO integration that fails open under some edge case. Tell the testing firm explicitly to focus time there rather than re-testing the base platform's own login form for the tenth time this year across their client base.

The findings I see repeated across different clients' reports

• Default or weak credentials on service accounts - an integration user created years ago with a password that was never rotated and doesn't follow the org's current password policy, because it predates that policy.
• Verbose error pages in production - a customization throwing an unhandled exception that surfaces a full stack trace, including internal class names and sometimes connection details, to an unauthenticated or low-privilege user.
• Missing server-side authorization on custom actions - exactly the "hidden button, no server check" pattern covered in the secure coding checklist, found by testers simply replaying a captured request with a different user's session.
• Session and cookie configuration - missing Secure/HttpOnly flags, or session timeout configured too generously for a system handling financial data, both of which are IIS/web.config settings rather than anything in customization code.

Test your own custom REST surface before the pen tester does

Any custom endpoint exposed through a Business Event's REST action, a custom PXAction wired to a webhook, or a bespoke API controller is code your team wrote and is fully your responsibility to have tested, not the platform's. Run the basics yourself before an external test does it for you: hit the endpoint unauthenticated and confirm it rejects; hit it as a low-privilege user and confirm authorization is enforced server-side, not assumed from the caller; and send malformed or oversized payloads and confirm the failure mode is a clean error, not an unhandled exception leaking internals.

[HttpPost]
[Route("api/custom/inboundwebhook")]
public IHttpActionResult Receive([FromBody] WebhookPayload payload)
{
    if (!ValidateSignature(Request.Headers, payload))
        return Unauthorized(); // reject before any business logic runs

    if (payload == null || string.IsNullOrEmpty(payload.EventId))
        return BadRequest("Malformed payload");

    // ... process
    return Ok();
}

Triaging findings: not everything is equally urgent

A pen test report typically lands with a dozen findings ranked Critical/High/Medium/Low by the testing firm's own scale, which doesn't always match actual business risk on your specific instance. I re-triage against what the finding actually exposes on this client's data - a missing security header is genuinely Low on an instance with no PII exposure risk from it, while a permission gap on a custom action that can modify GL transactions is Critical regardless of what the generic scoring template says. Push back on a report's severity ratings when they don't reflect your system's actual risk; testing firms use a general-purpose rubric that doesn't know your data model.

Wrapping up

Penetration tests against Acumatica instances almost never find platform-level issues; they find gaps in the custom layer - unrotated service credentials, verbose error output, missing server-side checks on custom actions, and web-tier configuration nobody revisited since go-live. Test your own custom endpoints with the same rigor before an external firm does, and re-triage findings against your instance's actual data sensitivity rather than accepting a generic severity scale at face value.