A practical Epicor Kinetic security audit: users, Security Manager rights, menu security and REST API access

How the Security layers fit together

Menu security is not system security. Hiding a menu item only removes that screen from the client navigation menu. Process security provides direct server-side control over access to business objects and methods. Because Kinetic uses an API-first architecture, an authenticated user or script calling the REST API hits the exact same server-side business objects as the Kinetic web client. If a business object remains unrestricted in Process Security Maintenance, an authenticated user with general network access can query or modify it via REST, OData feeds, or external tools regardless of menu restrictions.

Step by step: A six-point Security audit

Always validate audit queries and planned security changes in Pilot before applying them in Production.

1. Find and audit every Security Manager

The Security Manager flag grants total administrative bypass across the entire system. It overrides all Menu Security restrictions and bypasses Field Security, allowing the holder to view unmasked data and update protected fields. Treat Security Manager as a break-glass administrative role, not a routine user convenience.

The Check: Build a BAQ on Ice.SysUserFile, or execute a read-only SQL query on-premises:

SELECT 
    UserID, 
    Name, 
    EMailAddress, 
    SecurityMgr, 
    CanImpersonate, 
    UserDisabled
FROM Ice.SysUserFile
WHERE SecurityMgr = 1 OR CanImpersonate = 1
ORDER BY UserDisabled, UserID;

Remediation Steps:

• Remove Security Manager from non-administrators: Department managers, project leads, and external consultants are frequently given Security Manager during implementation to bypass setup errors and rarely have it revoked at go-live. Revoke these assignments.
• Delegate specific functional rights: Grant power users specific permissions through Security Groups (such as BAQ Advanced User or BPM design permissions in Pilot/Development environments) rather than assigning system-wide Security Manager rights.
• Review quarterly: Maintain a strict roster of named administrators (typically two to three individuals) and audit it every quarter.
• Inspect Session Impersonation (CanImpersonate): The CanImpersonate flag permits an account to call server routines under another user's identity. Restrict this exclusively to dedicated system integration accounts that explicitly require it. Note that in Epicor Cloud (SaaS), tenant administrators cannot arbitrarily enable impersonation; doing so requires a formal support request handled by Epicor Cloud Operations under the Global Security Manager (GSM) role.

2. Handle leavers: Disable, do not delete

When an employee or contractor departs:

• Disable the account in User Account Security Maintenance: Tick User Disabled on the user record. Crucially, confirm this is set on the framework account (Ice.SysUserFile). Disabling or deactivating only the ERP-layer profile (Erp.UserFile) can leave the framework account active, permitting the user to continue authenticating.
• Strip group memberships: Remove security group assignments from the disabled account, or move the user to a dedicated "Terminated Users" group to keep security auditing clean.
• Disable SSO / Identity Provider access: If using Microsoft Entra ID or an external identity provider, disable or revoke the user's corporate directory identity immediately.
• Reassign transactional responsibilities: Before deactivating the user, reassign active workflows:
  • Open Purchase Orders and PO approval limits in Buyer Maintenance.
  • Active quotes, opportunities, and sales orders in Workforce Maintenance.
  • Scheduled reports, alerts, or tasks assigned to the user in System Monitor / Task Agent.
  • Authorized Signer or Approval Roles in AP/AR workflows.
• Preserve the user record: Never delete a user account from Epicor. The UserID is stamped across historical audit trails, journal entries, transaction tables (CreatedBy, ChangedBy), and change logs. Deleting user records risks referential integrity errors and destroys historical auditability.

3. Make menu Security consistent across all access paths

In Epicor Kinetic, a program often exists in multiple menu locations (e.g., Part Tracker appearing under Sales Management, Material Management, and Production Management). Furthermore, right-click context menus ("Open With") launch a specific, preconfigured Menu ID. Kinetic evaluates permissions against the specific Menu ID being launched. If you secure one menu item for a sensitive screen but leave an alternate Menu ID or setup copy open, users can bypass your intended restriction.

How to Audit Menu Consistency:

1. Build a BAQ on Ice.Menu querying the program (Program or OptionPath) to identify every menu entry that launches it, along with its assigned SecCode.
2. Compare the security assigned to each instance. Ensure every menu item pointing to the same sensitive screen shares the same restrictive security code.
3. Audit Context Menus ("Open With"): In Context Menu Maintenance, inspect which Menu ID is mapped to right-click actions for key fields (such as PartNum, CustID, or VendorID). If the context menu points to an open Menu ID, users denied access via the main menu can still open the program via right-click. Align the target Menu ID's security accordingly.
4. Inspect Process Calling Maintenance: Process Calling can intercept standard screen invocations and redirect them to custom Menu IDs. Verify that redirected Menu IDs do not carry looser permissions than the source screen.
5. Enforce folder vs. item security: Securing a menu folder does not automatically inherit down to all child items if those items were configured independently. Always verify security at the individual menu item level.
6. Apply the definitive fix: If users must be blocked from seeing or modifying underlying data under all circumstances, lock down the Business Object in Process Security Maintenance. Menu security hides the interface; process security locks the engine.

4. Lock down business objects and REST API access

Any authenticated user with valid network access can query the Kinetic REST API from tools like Excel, Power BI, Python, or Postman.

• REST API v1 vs. v2: REST API v2 requires an API Key (X-API-Key header) by default in addition to user authentication. REST API v1 in older environments may allow calls using basic authentication alone unless the server configuration has been explicitly set to mandate API keys.
• Process Security on Sensitive Services: Open Process Security Maintenance and restrict sensitive business objects (such as Erp.BO.PayrollCheckSvc, Erp.BO.EmpBasicSvc, Erp.BO.BankRecSvc, and Erp.BO.PartCostSearchSvc) to designated security groups. Where users need read access but must not alter records, secure individual methods such as Update, UpdateMaster, and DeleteByID.
• One API Key Per Integration: Never share a single API key across multiple external applications. Issue a distinct key for each integration (e.g., eCommerce, CRM, Shipping, EDI).
• Narrow Access Scopes: Always bind every API key to an Access Scope configured in Access Scope Maintenance. Limit the scope strictly to the specific Business Objects, BAQs, or Epicor Functions that the integration requires.
• Dedicated Integration User Accounts: Run external integrations under dedicated service accounts configured with the principle of least privilege. Never execute integration calls under personal user accounts, and never assign SecurityMgr to an integration user.

5. Document and test field Security

Field Security Maintenance provides granular control over individual database columns (such as unit costs, burden rates, bank account numbers, or executive compensation).

Operational Pitfalls to Avoid:

• The "Invisible Rule" Problem: Field security configurations do not display visual indicators in Application Studio or on standard forms. When a field unexpectedly appears blank or fails to save for specific users, administrators often spend hours troubleshooting UI layers or BPMs before remembering field security exists.
• Shared BAQ and Dashboard Discrepancies: When a shared BAQ or dashboard queries a field secured against the executing user, the column returns NULL or masked data for that user, while displaying complete data for the author or administrator. Always test shared analytics while signed in as a restricted test user. Where sensitive financial or cost data is involved, design separate BAQs tailored to specific user tiers rather than relying solely on dynamic column suppression.
• BPM and Epicor Function Execution Context: Custom business logic (BPMs and Functions) executing in the user's session runs within that user's security context. If the user lacks read or write rights to a secured field, the directive may fail or process incomplete data unless written to handle restricted columns.
• Governance Standard: Maintain an offline register detailing every active field security rule (Table, Field, Assigned Security Groups, Business Justification, and Owner). Assign field-level restrictions to Security Groups rather than individual user accounts.

6. Disable forgotten client and server tracing

Trace logging enabled during debugging sessions is frequently forgotten. On-premises environments and Classic Smart Client workstations have seen local drives filled with dozens or hundreds of gigabytes of trace logs because the client does not automatically purge historical trace files. Server-side tracing similarly degrades system performance and fills application server disks.

The Check: Identify active tracing flags in Ice.UserTracing:

SELECT 
    UserID, 
    DataTrace, 
    ServerTrace, 
    DBTrace, 
    TraceXml
FROM Ice.UserTracing
WHERE DataTrace = 1 OR ServerTrace = 1 OR DBTrace = 1;

Remediation: Disable tracing for any account not actively engaged in diagnostic troubleshooting.

Audit checklist: Symptom, Risk, and Remediation

Edge cases to plan for

• Post-Upgrade Menu Additions: Version upgrades and major point releases frequently introduce new standard menu items, reports, and trackers. Always diff your menu security configuration against your established baseline in Pilot before upgrading Production.
• Single Sign-On (SSO) Transitions: When migrating authentication to Microsoft Entra ID or Okta, decouple external integrations from personal user credentials by converting them to dedicated service accounts with scoped API keys.
• Segregation of Duties (SoD): Enforce development lifecycle boundaries. Allow power users and developers to build BPMs, Application Studio layers, and BAQs only in Pilot or Development environments. Promoted changes should be deployed to Production exclusively by designated change administrators.

FAQ

How many Security Managers should a production environment have?

As few as possible—typically two to three named system administrators. Day-to-day work should be performed using standard user accounts, reserving administrative accounts strictly for authorized system maintenance.

Can I restrict a user's access to a single site or plant?

Partially. User Account Security Maintenance restricts the companies and sites a user can sign in to. However, this does not automatically filter BAQs, dashboards, or global searches that query multi-site data. Queries requiring site-level boundaries must explicitly filter by Plant (or join through PlantWhse for inventory).

What is the exact operational difference between Menu Security and Process Security?

Menu security controls UI visibility within the Kinetic client navigation tree. Process security controls whether the server executes the underlying Business Object methods. Menu security hides the door; process security locks the vault.

Why is deleting inactive user accounts prohibited?

User IDs are permanently recorded on historical audit logs, financial transactions, and change records (CreatedBy, ChangedBy). Deleting an account destroys audit traceability and can trigger database referential integrity errors. Always use the User Disabled flag.

Does REST API v2 mandate an API Key?

Yes. REST API v2 requires an API Key (X-API-Key header) by default in addition to valid user authentication. The key should always be constrained by an Access Scope configured in Access Scope Maintenance.