ERP and CRM integrations create pathways into customer, financial, employee, supplier and operational data. A connection that works functionally can still expose excessive permissions, long-lived credentials or sensitive information through logs. Security must be designed into the integration lifecycle—from identity and API boundaries to monitoring, recovery and supplier access.
Map the integration attack surface
Inventory APIs, middleware workflows, service accounts, scheduled jobs, file transfers, webhooks, database connections and third-party applications. For each connection, record the business and technical owner, data categories, direction, environment, authentication method, permissions, network path, credential location and support contact. Classify the data exchanged. Customer details, payroll, bank information, supplier records and commercially sensitive transactions require different controls. Minimise fields and records transferred to what the receiving process actually needs.
Use workload identities and least privilege
Integrations should authenticate as identifiable applications or workloads, not shared employee accounts. Where supported, use managed identities or certificate-based authentication. For OAuth-based APIs, define narrow scopes, validate tokens at the API boundary, and separate development, test and production identities.
Apply least privilege to read and write operations. A reporting integration may need read access to selected entities but should not create vendors or post journals. A CRM sync may update approved customer attributes but should not have unrestricted access to finance transactions. Separate platform administration from runtime access; developers who deploy an integration do not automatically need broad production-data access. Review permissions periodically and remove unused grants.
Protect credentials and secrets
- Do not hard-code passwords, API keys, certificates or connection strings in source code, scripts, tickets or repositories.
- Use a dedicated secrets manager or vault with role-based access and audit logging.
- Prefer short-lived tokens and managed identities where practical.
- Use distinct credentials for different consumers so one compromised integration can be revoked without disrupting unrelated services.
- Rotate secrets and certificates through a tested process; confirm dependent services can switch without an outage.
- Scan repositories and deployment pipelines for exposed secrets. Treat a discovered credential as compromised and revoke it.
Microsoft’s secrets protection guidance covers discovery, secure storage, access control, lifecycle management and monitoring. The principles apply even when the integration platform is not hosted on Azure.
Secure the API boundary
An API gateway or management layer can centralise authentication, authorisation, schema validation, rate limits and traffic policies. It is not a substitute for backend authorisation: the receiving application must still enforce permissions relevant to the requested business action.
- Require TLS for data in transit and validate certificates.
- Use OAuth 2.0 or appropriate certificate-based mechanisms rather than treating a static subscription key as application identity.
- Validate request bodies, parameters, headers and content types.
- Apply rate limits and quotas to protect ERP and CRM services from spikes or abusive clients.
- Restrict exposed endpoints and network paths; do not publish internal administration APIs.
- Use allowlists or private connectivity where supported by the threat model.
- Version APIs deliberately and retire obsolete versions with consumer notice.
See Microsoft’s API Management security recommendations for gateway validation, OAuth and Entra ID token checks, least privilege and traffic controls.
Protect the data itself
Authentication answers who is calling; data protection determines what the caller can see and change. Use field- or entity-level controls where supported, mask sensitive values in non-production environments, and avoid copying production data into developer sandboxes without a documented need and safeguards. For file-based integrations, encrypt files in transit and at rest, use controlled storage locations, restrict downloads and define retention and deletion rules. Avoid sending full customer or employee records when a small set of identifiers and status fields will satisfy the process.
Design safe failure handling
Retries can create security and integrity problems when they replay a non-idempotent business action. Use idempotency keys or stable external transaction identifiers for operations that must not be duplicated. Apply bounded retries with exponential backoff for transient failures, and route permanent validation errors to a controlled exception queue. Do not place passwords, access tokens, payment data or unnecessary personal information in error messages. Give support teams enough context to diagnose an issue without exposing the payload. Define who can inspect, replay, correct or delete failed messages.
Monitor security and business behaviour
Collect logs from API gateways, integration runtimes, identity providers, secrets stores and source applications. Correlate events using a request or transaction ID that follows the message across systems. Synchronise clocks and retain logs according to legal, regulatory and operational requirements.
Monitor unusual authentication failures, token issuance or privilege changes; unexpected source IPs, identities or access times; sudden increases in API volume, payload size, throttling or rejected requests; repeated access to sensitive entities or bulk exports; changes to secrets and API policies; growing queues, replay spikes, failed synchronisation and reconciliation differences. Pair security monitoring with business reconciliation: a connection may be technically healthy while silently omitting records or writing incorrect values.
Prepare an integration incident playbook
- Identify the affected integration, identity, endpoints and data domains.
- Contain the incident by disabling the identity, revoking credentials, restricting network access or pausing the workflow.
- Preserve logs and message metadata for investigation.
- Determine which records were read, changed, exported, duplicated or missed.
- Rotate exposed credentials and validate dependent connections before restoring service.
- Reconcile affected transactions and use controlled replay or correction procedures.
- Document root cause, notification obligations, control gaps and follow-up owners.
Security testing before go-live
Include security requirements in integration acceptance criteria. Test authentication expiry, revoked credentials, invalid scopes, role changes, malformed payloads, rate limiting, replay attempts, logging redaction, certificate renewal and recovery after service interruption. Verify that non-production environments do not expose production secrets or unrestricted live data. Run threat modelling for integrations crossing trust boundaries, exposing public endpoints or processing regulated information. Include vendors and implementation partners in access reviews, contract controls and offboarding procedures.
Practical security checklist
| Control | Evidence to retain |
|---|---|
| Identity and access | Named workload identity, scoped permissions, periodic access review |
| Secrets | Vault location, rotation owner, access audit and scanning results |
| API protection | Authentication policy, schema validation, throttling and network restrictions |
| Data minimisation | Approved field map, classification and retention rules |
| Resilience | Retry limits, idempotency design, exception queue and replay approval |
| Monitoring | Correlated logs, alerts, dashboards and reconciliation reports |
| Incident response | Containment steps, credential revocation and transaction recovery runbook |
Related reading
For architecture decisions, see our ERP integration architecture guide and ERP integration testing checklist. Our CRM–ERP integration guide explains ownership and synchronisation controls.
Bottom line
Secure integrations require more than encrypted connections. Use identifiable workloads, narrow permissions, protected secrets, validated API boundaries, data minimisation, safe retries and correlated monitoring. Assign owners for each control and rehearse credential revocation and transaction recovery before an incident occurs.
