# Infor M3 MI API and ION API Gateway Security Checklist > Source: https://netray.co/tools/infor-m3-mi-api-security-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Security checklist for on-prem M3 13.x integrations using MI programs over REST and the ION API gateway: accounts, authorization, transport, monitoring and lifecycle. ## Category infor-cloudsuite ## Erp Infor M3 ## Audience - M3 system administrator - Integration developer - IT security ## Tool **Kind:** checklist **Groups:** #### Accounts **Items:** **Text:** Each integration has its own M3 user in MNS150, not a shared or personal account **Critical:** true Integration users are connected only to roles built for that integration (MNS405 roles, MNS410 user-role connections) ION API clients for backend services use service accounts, and each service account maps to one integration Passwords and service account secrets have an owner and a rotation schedule Integration users cannot log on interactively, or interactive use is monitored **Text:** Every integration account is listed with owner, purpose and systems that use it **Critical:** true #### Authorization **Items:** **Text:** API authority is restricted per API program and transaction (Function. Connect API Authorization, SES005); do not rely on the default open access **Critical:** true Function authority for integration roles is set by role in SES400 **Text:** EXPORTMI and MDBREADMI are blocked for integration users unless a reviewed need exists, because they can read table data broadly **Critical:** true Integration users are restricted to the companies and divisions they need Update and delete transactions are granted only where the integration writes data Authority is tested with the integration user itself, not with an administrator account #### Transport **Items:** **Text:** MI REST calls (m3api-rest) and the ION API gateway are reachable over HTTPS only **Critical:** true No basic authentication is sent over plain HTTP anywhere in the chain **Text:** .ionapi files are stored as secrets in a vault or protected configuration, never in source control **Critical:** true ION API client secrets are rotated and old ones revoked Network access to MI ports and the gateway is limited to known integration hosts Certificates are valid, monitored for expiry and use current TLS versions #### Monitoring **Items:** API usage is logged per user and transaction and logs are retained for the audit period Alerts fire on repeated failed logons for integration users **Text:** Unusual EXPORTMI or MDBREADMI volume, or use by an unexpected user, raises an alert **Critical:** true Integration errors are visible to an owner, not only in a log file #### Lifecycle **Items:** Unused API clients and integration users are removed after a set period of inactivity API authority is reviewed after every upgrade, because new programs and transactions appear **Text:** Integration accounts are included in the periodic user access review **Critical:** true Decommissioned integrations have their accounts, secrets and network rules removed the same day **Scoring Note:** The critical items close the gaps most often found in M3 integration reviews: shared accounts, open API authority, broad table-read programs and secrets in files. Treat any unchecked critical item as an open risk with an owner and date. ## Content **Intro:** This checklist secures integrations into an on-prem Infor M3 13.x system that use MI programs, either directly through the m3api-rest endpoint or through the ION API gateway. It covers accounts, authorization, transport, monitoring and lifecycle. **Sections:** #### Where M3 API security lives **Body:** Every MI call runs as an M3 user, defined in MNS150. That user's roles (MNS405, connected in MNS410) and function security (SES400) apply, and API access can be restricted per API program and transaction in Function. Connect API Authorization (SES005). By default, users can reach every API program and transaction, so without SES005 entries an integration account can call far more than it needs. All API programs restrict users to the companies they have access to, and some apply field, facility or warehouse restrictions on top. The ION API gateway adds OAuth 2.0 clients defined in ION API, whose credentials are distributed as .ionapi files. **Bullets:** - MNS150: user - MNS405 / MNS410: roles and user-role connection - SES400: function authority by role - SES005: API authority by program and transaction #### Why EXPORTMI and MDBREADMI deserve attention **Body:** EXPORTMI and MDBREADMI are generic MI programs that read M3 table data, which makes them convenient for reporting and lookups and also the easiest way for an integration account to read much more than its purpose. Treat them as privileged. Grant them only to accounts with a reviewed need, prefer specific MI programs such as MMS200MI or OIS100MI transactions where they exist, and alert on unusual use. Remember that hiding a button in a client is usability, not security: the backend authority is what stops a call. #### How to use it **Body:** Start with the inventory: list every integration, its M3 user, its ION API client if any, and the MI programs it calls. Then go through the groups with the M3 administrator and the integration owner. For Authorization, test with the integration user itself by calling a transaction it should not have and confirming it is refused. Critical items should be closed before a new integration goes live and checked again after every upgrade. Export the result to PDF as evidence for the access review. #### Common mistakes **Body:** One generic integration user shared by every interface, so nobody can tell which system made a change. .ionapi files committed to a Git repository or left on a shared drive. Test integrations pointing at production with an administrator account. Basic authentication to m3api-rest over HTTP on an internal network that turns out to be less internal than assumed. And API authority that was never reviewed after an upgrade added new transactions to programs the integration already had. **Cta:** If you want a private AI assistant to call M3 through read-only, authority-checked MI transactions on your own servers, we can set that up. **Faq:** #### How do I restrict which M3 APIs a user can call? **Answer:** Use Function. Connect API Authorization (SES005) to restrict access per API program and transaction, combined with role-based function security in SES400. Without SES005 restrictions users can access every API program and transaction by default. Test the restriction by calling a disallowed transaction as the integration user. #### What is the Infor M3 API gateway? **Answer:** It is the ION API gateway, part of Infor OS, which publishes M3 MI programs and other Infor APIs as REST endpoints secured with OAuth 2.0. Client credentials are created in ION API and downloaded as .ionapi files. On-prem M3 can also expose MI over REST directly through m3api-rest. #### Is it safe to use EXPORTMI for integrations? **Answer:** It can be, for a reviewed use with a dedicated account, but it reads table data broadly, so it is a common source of over-exposure. Prefer specific MI transactions where they exist, restrict EXPORTMI through API authority to the accounts that need it, and alert on unexpected use or volume. #### Where should .ionapi files be stored? **Answer:** In a secret store or vault, or protected configuration readable only by the integration's service account. Never in source control, email or a shared folder. If a file was exposed, revoke the client secret in ION API, create a new one and distribute it only to the service that needs it. ## Search terms infor m3 api security, infor m3 api gateway, infor m3 rest api, infor m3 api, infor m3 security settings, infor m3 mi program, infor m3 api documentation, api integration in infor m3 --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json