Enterprise Integration Security and the Hidden Risk in Connected Systems

Enterprise integration security has shifted from a back-office concern to a central corporate IT question. Most large organizations now run hundreds of software services, and those services deliver value only when they exchange data: a customer record flows from a CRM to a billing system, a file moves from a partner to a payroll provider, and an AI assistant reads tickets from a support platform. Each of those connections carries credentials, permissions, and data. When attackers find the weakest link, they rarely need to break the core system itself.

This explainer explains how integrations work in practice, what recent incidents reveal about their failure modes, which standards security teams rely on, and how regulators have raised the stakes. It closes with questions buyers can put to vendors before connecting a new product to systems that hold sensitive data.

Why Integrations Became the Soft Middle of Enterprise IT

For years, enterprise security focused on two ends of the stack: the perimeter, where users and attackers arrive, and the core applications and databases that hold valuable records. The connective tissue between them received less attention. Project teams often built integrations under deadline pressure, configured them once, and then left them running for years with broad permissions and long-lived credentials.

The shift to cloud software multiplied those connections. A single SaaS application can expose dozens of API endpoints and support marketplace add-ons that request access on users’ behalf. Each add-on is effectively a new identity inside the business, often with read or write access to data that its owners never reviewed. Security teams that maintain a careful inventory of employee accounts may have only a partial view of the machine identities, tokens and service accounts that integrations depend on.

The National Institute of Standards and Technology made this point in its June 2025 guidance on API protection, noting that enterprise IT relies on APIs for integration and that secure API deployment is critical to overall enterprise security. In that framing, integration is part of the attack surface, not plumbing, and deserves the same design reviews, monitoring and ownership as any customer-facing application. Coverage in TechAmerica.ai’s enterprise technology section shows how quickly companies are adding AI agents and new software hubs, each adding more connections to manage.

How Modern Integration Works, and Where It Breaks

Enterprise integration is not one technology. It is a collection of patterns that have accumulated over decades, and many organizations run them all at once. Understanding each pattern helps explain where the risks concentrate.

APIs and Gateways

Most new integrations use web APIs, typically REST or GraphQL interfaces that accept requests and return structured data. An API gateway often sits in front of them to handle authentication, rate limiting and logging. The risk is less about the protocol than about authorization logic. If an API checks that a caller is logged in but not whether that caller should see a particular record, anyone with a valid account can request other customers’ data simply by changing an identifier in the request.

OAuth Tokens and Connected Apps

When one cloud service connects to another, it usually relies on OAuth, a framework that lets a user grant an application limited access without sharing a password. The application receives an access token and often a refresh token that can generate new access tokens for months. Those tokens are powerful. They frequently bypass multifactor authentication because the user approved the connection once, and they may carry scopes far broader than the integration actually needs.

File Transfer and Batch Pipelines

Older but still widespread, managed file transfer platforms and scheduled batch jobs move large volumes of data between companies, such as payroll files, claims records and inventory feeds. These systems are often exposed to the internet so partners can reach them, and they tend to hold the kind of bulk data extortion groups prize.

Integration Platforms and Middleware

Integration platform-as-a-service products, enterprise service buses, and low-code automation tools sit in the middle of many of these flows. They simplify development by centralizing connectors and credentials. The tradeoff is concentration: a single compromised middleware account can expose credentials for many downstream systems at once.

What Recent Incidents Show

Two widely documented campaigns illustrate how attackers exploit integration layers rather than the systems of record behind them.

In June 2023, the Cybersecurity and Infrastructure Security Agency and the FBI published an advisory on the CL0P ransomware gang exploiting a SQL injection vulnerability, tracked as CVE-2023-34362, in Progress Software’s MOVEit Transfer, a managed file transfer product. According to the advisory, exploitation began on May 27, 2023, while the flaw was still a zero-day. The attackers installed a web shell the agencies named LEMURLOOT, first observed as a file called human2.aspx, and used it to steal data. Because MOVEit was used to exchange files with many partners, a single product flaw exposed data belonging to organizations that had never run the software themselves.

A second pattern emerged in 2025 around Salesforce environments. On September 12, 2025, the FBI issued a FLASH alert describing two threat clusters, tracked as UNC6040 and UNC6395. According to the alert, UNC6040 used voice phishing to persuade employees to connect a malicious version of a data-loading tool to their company’s Salesforce instance, then exported records in bulk. UNC6395 took a different route: it used OAuth and refresh tokens stolen from the Salesloft Drift integration, with activity believed to have occurred between August 8 and 18, 2025. Salesloft worked with Salesforce to revoke Drift tokens and require customers to reauthenticate.

The two cases share a lesson. In neither case did attackers need to defeat the core platform’s security. They used a trusted connection, a file transfer service in one case and an approved third-party integration in the other, to reach data at scale. Reporting on exposures such as misconfigured hosted databases leaking personal data points to a related problem: defaults and configurations that nobody revisits after deployment.

The Standards Security Teams Rely On

Security teams do not have to invent a framework for integration risk. Several public references give structure to reviews and vendor conversations.

The OWASP API Security Top 10, updated in 2023, lists the most common categories of API weakness. Three of the top five involve authorization: broken object-level authorization, broken object property-level authorization and broken function-level authorization. The list also includes improper inventory management, which describes organizations that do not know which API versions and endpoints they expose, and unsafe consumption of APIs, which covers the risk of trusting data returned by third-party services too readily. That final category is directly relevant to integration because it reminds teams that a partner's API can be both a source of attack and a target.

NIST Special Publication 800-228, Guidelines for API Protection for Cloud-Native Systems, was published in June 2025, and NIST released an update in March 2026. The document identifies risk factors across the API lifecycle, recommends basic and advanced controls for both the pre-runtime and runtime stages, and compares implementation options such as gateways and service meshes. Its emphasis on an incremental, risk-based approach helps organizations that cannot overhaul every integration at once.

The FBI’s 2025 alert also offered concrete, integration-specific mitigations. They included requiring phishing-resistant multifactor authentication, applying least privilege to accounts and groups, enforcing IP-based access restrictions, monitoring API usage for unusual behavior, reviewing all third-party integrations connected to software instances, and rotating API keys, credentials and authentication tokens for each application.

• Inventory: know every integration, its owner, its scopes and the data it can reach.
• Authorization: test object- and function-level access as well as login.
• Credential hygiene: prefer short-lived tokens and rotate long-lived secrets on a schedule.
• Monitoring: alert on unusual export volumes, new connected apps and access from unexpected locations.

Regulatory Pressure and Disclosure Obligations

Integration failures are no longer only an operational problem. For public companies in the United States, they can quickly become a disclosure question.

Rules adopted by the Securities and Exchange Commission in 2023 require registrants to disclose a material cybersecurity incident on Form 8-K under Item 1.05 within four business days after determining that the incident is material. The disclosure must describe the nature, scope and timing of the incident and its material or reasonably likely material impact. Large registrants began complying with Item 1.05 in December 2023, and smaller reporting companies followed in June 2024.

The same rules added Regulation S-K Item 106, which requires companies to describe in annual reports how they assess and manage material cybersecurity risks. That description includes whether they have processes to oversee and identify material risks associated with using third-party service providers. For integration teams, this means boards and investors now expect vendor connections to be governed and described.

Sector rules add further layers. Healthcare organizations, financial institutions, and government contractors each face obligations governing how they share data with service providers and how they report incidents. The specifics vary by sector and jurisdiction, and they change, so integration reviews in regulated industries should involve legal and compliance staff from the start rather than after a connection is live. For that reason, developments in the government and policy section are worth tracking.

Verifying Vendor Claims About Integration Security

Vendors routinely describe their products as secure, compliant or enterprise-ready. Those phrases are not evidence. Buyers who want to verify claims need to look past marketing pages to documentation and independent assurance.

Start with scope. A third-party audit report or certification matters only if it covers the systems that will handle your data, including integration services and connectors, not just the vendor’s core application or corporate IT. Ask for the scope statement and check the dates. A report that covers a period before a major architecture change may describe a different system.

Next, examine how the product requests access. Does the integration ask for only the permissions it needs, or does it default to broad administrator scopes? Can administrators see and restrict which objects and fields a connected app can read? Are refresh tokens lifetime-limited, and can they be revoked centrally? Products that make these controls visible and configurable give security teams something to verify. Products that hide them behind a single consent screen do not.

Finally, look at incident history and response. How did the vendor communicate during past security events? Did it publish technical details, revoke credentials proactively and give customers clear remediation steps? The response to the Drift incident, where tokens were revoked and customers had to reauthenticate, shows the kind of decisive action that limits damage, even if it is disruptive. A vendor that cannot describe its revocation process in advance is unlikely to execute one well under pressure.

Questions Buyers Should Ask Before Connecting a New Product

Procurement and security reviews often rely on long questionnaires that vendors answer from templates. A shorter set of targeted questions, asked in a live conversation with technical staff, tends to reveal more.

1. Which specific data objects and fields will the integration read or write, and can we restrict them?
2. What type of credential does the integration use, how long does it live, and how do we rotate or revoke it?
3. Where do you store our tokens and secrets, and who on your staff can access them?
4. What logs will we receive about the integration’s activity, and in what format and timeframe?
5. How would you notify us if your integration infrastructure or source code repositories were compromised?
6. Which subprocessors or downstream services receive our data through this connection?
7. Does your most recent independent assessment cover the integration components, and when did its review period end?
8. How do you test your own APIs for authorization flaws such as those in the OWASP API Security Top 10?

The answers do not need to be perfect. The test is whether the vendor can answer specifically and consistently, and whether its answers match what the documentation and contract say. Vague answers to questions about token storage and revocation deserve particular scrutiny, given how recent campaigns have unfolded.

Resilience belongs in the same conversation. Integrations create dependencies and exposures, and a disruption at a large provider can ripple across connected workflows, as TechAmerica.ai’s coverage of a Microsoft 365 outage affecting Outlook illustrated. Buyers should ask how an integration behaves when an upstream service is unavailable, whether it queues or drops data, and how it recovers.

What Good Practice Looks Like Now

No organization can eliminate integration risk. Businesses need connected systems, and every connection creates some exposure. The realistic goal is to make that exposure visible, bounded and recoverable.

Visibility starts with an inventory that treats integrations as identities, each with an owner, a purpose, a set of permissions and a review date. Bounding exposure means granting the narrowest scopes possible, preferring short-lived credentials, restricting where tokens can be used from and segmenting systems that handle file transfers or bulk exports. Recoverability depends on rehearsed procedures to revoke and reissue credentials across many systems at once, along with logs detailed enough to show what data a compromised connection actually touched.

Organizational ownership is often the hardest part. Integrations sit between teams: the application owner, the security group, procurement and the vendor. When a connection breaks or is abused, it is common to find that nobody considered it theirs. Assigning clear owners and building integration review into procurement rather than treating it as a later technical task closes much of that gap.

The rise of AI agents that act across multiple applications will make these questions more pressing, not less. From a security standpoint, an agent that can read email, update records, and trigger workflows is an integration with unusually broad reach. The same principles apply: know what it can access, limit that access to what the task requires, watch what it does and be ready to cut it off. Organizations that have already built discipline around conventional integrations will be better placed to govern AI agents and the other connected tools that follow.