How to Architect SaaS Integrations for EU NIS2 Compliance & Supply Chain Security

If you are selling B2B SaaS into the European Union in 2026, and your product ships any third-party integrations—HRIS, CRM, accounting, ticketing, or identity—your integration architecture is now a regulated piece of someone else's cybersecurity supply chain. Answering the question of how to architect third-party SaaS integrations to meet EU NIS2 compliance and supply chain risk requirements requires a fundamental shift in how engineering teams handle third-party data.

Under the NIS2 directive, you can no longer brush off integration security with a generic SOC 2 report. If your integration layer—whether built in-house, outsourced to a custom development agency, or powered by a legacy iPaaS—stores customer payload data at rest, you are operating a high-risk centralized honeypot that will fail strict enterprise procurement audits.

To pass NIS2 supply chain security requirements, engineering teams must abandon stateful, data-hoarding integration platforms. The correct architectural pattern is a zero-data-retention, pass-through execution engine that normalizes API requests in memory and immediately discards the payload.

This guide breaks down exactly how NIS2 Article 21 reshapes third-party vendor risk, the severe architectural flaws of legacy unified APIs, and the concrete patterns engineering leaders should use to build integrations that accelerate product delivery while surviving enterprise procurement.

The 2026 Reality: Why NIS2 Makes SaaS Integrations a Massive Liability

The Network and Information Security (NIS2) directive fundamentally alters the calculus of building software integrations for the European market. Unlike previous frameworks that focused primarily on internal infrastructure, NIS2 explicitly targets the software supply chain.

NIS2 (Directive 2022/2555) dramatically expanded the regulatory perimeter compared to its predecessor. An estimated 160,000 or more entities are now in scope across the European Union, up from roughly 10,000 under NIS1. The directive imposes four categories of obligation: risk management measures, incident reporting, supply chain security, and governance accountability.

The part that lands directly on integration vendors is Article 21. At the entity level, NIS2 Article 21(2)(d) requires organizations to address supply chain risks in their cybersecurity measures, including security-related aspects of relationships with direct suppliers and service providers. This means the enterprise buyer's CISO is now legally obligated to audit your third-party sub-processors. When your SaaS product connects to an enterprise's Salesforce, Workday, or NetSuite instance, the infrastructure facilitating that connection becomes part of their regulated attack surface.

In practical terms, NIS2 Article 21 supply chain requirements mean entities need to assess the cybersecurity practices of their direct suppliers, not just contractually require them to be compliant. This translates directly to 300-question SIG Core spreadsheets, evidence requests, and proportionate right-to-audit clauses—a common hurdle we see when teams try to pass enterprise security reviews with 3rd-party API aggregators.

The penalties for failing to secure this supply chain are severe. For essential entities, NIS2 imposes fines of up to €10 million or 2% of global annual revenue for non-compliance, alongside personal management accountability for gross negligence. Executive management is personally liable, and waiver of liability is legally excluded in several national transpositions.

For SaaS product managers and engineering leaders, this translates directly to stalled deals. If your integration architecture cannot prove strict data isolation, zero payload retention, and secure token management, the deal dies. (This regulatory pressure mirrors the strict requirements we see in the financial sector; see our guide on managing API risk for DORA compliance for parallel context).

The Cost of Compromise: SaaS-to-SaaS Supply Chain Attack Statistics

Enterprise procurement teams are aggressively auditing SaaS integrations because SaaS-to-SaaS connections are the modern attacker's preferred lateral movement vector. The risk profile justifying NIS2 is not abstract; it is written in the incident logs of the past year.

Consider the operational reality of 2026:

• Third-party breaches have doubled: According to the Verizon Data Breach Investigations Report (DBIR) 2025, which analyzed over 12,000 breaches globally, 30% of all data breaches now involve a third-party supply chain vulnerability. This represents a 100% increase year-over-year.
• The financial impact is devastating: IBM's Cost of a Data Breach 2025 report states that third-party vendor and supply chain compromises cost an average of $4.91 million per incident.
• OAuth tokens are the new perimeter: Threat actors are actively exploiting OAuth tokens and API keys. The DBIR notes that stolen credentials account for 32% of top attack methods. Once an attacker compromises a poorly secured integration platform, they use stolen refresh tokens to infiltrate connected SaaS environments without ever triggering traditional endpoint security controls.
• Secrets linger far too long: The median time to remediate leaked secrets discovered in a GitHub repository is 94 days—which is roughly an eternity in a token-theft scenario.
• Cascading operational failures: Service provider breaches like Change Healthcare, CDK Global, and Blue Yonder did not just expose data. They created operational downtime across entire industries, combining cybersecurity risk with operational risk.

When you embed a third-party workflow builder or legacy unified API into your product, you inherit their security posture. If they get breached, your enterprise customers get breached.

Why Legacy iPaaS and Data-Syncing Unified APIs Fail NIS2 Audits

Most B2B SaaS companies default to building integrations using embedded iPaaS (Integration Platform as a Service) tools or first-generation unified APIs. These platforms were built for developer convenience, not strict supply chain security.

Their fatal architectural flaw is stateful data caching.

A classic ETL-style unified API or visual workflow builder pulls every employee, contact, deal, or invoice from your customer's source system, normalizes it into a shared schema, and persists it in its own database or durable queue. The sales pitch is "sync once, query forever." The compliance reality looks entirely different:

• Centralized honeypot: The integration vendor now holds a copy of every customer's Workday, Salesforce, and Xero data. If a user syncs 10,000 employee records from BambooHR to your app, those records sit in a third-party Postgres table. A single breach exposes hundreds of downstream organizations.
• Sub-processor sprawl: Every cached dataset becomes a sub-processor disclosure, a DPA amendment, and a SIG questionnaire row. For EU enterprise clients, routing sensitive PII through a third-party database that you do not control is often an automatic disqualifier. If you are hitting this wall, you need an integration tool that doesn't store customer data.
• Token blast radius: Long-lived OAuth tokens for thousands of tenants stored in one place, alongside the raw data they access, are the highest-value target an attacker can pick.
• Incident scope ambiguity: When the integration vendor has a breach, your customer's CISO has to assume their data was in scope. Under NIS2's strict 24-hour early-warning clock for incident reporting, you cannot afford to say "we will get back to you next week."

Read more about the security implications of using a third-party unified API to understand exactly how procurement teams evaluate these architectures.

Architecting for Compliance: The Zero Data Retention Approach

To ship integrations quickly without failing NIS2 audits, you must adopt a zero data retention architecture. As we've covered in our breakdown of what zero data retention means for SaaS integrations, this means the integration layer acts purely as a stateless proxy and transformation engine. It receives the request, translates the schema in memory, authenticates the call, forwards it to the destination, and immediately drops the payload.

Core Principles of a Zero-Data-Retention Architecture

To capture enterprise deals, your integration infrastructure must guarantee the following:

• In-Memory Processing Only: As detailed in our guide on how to ensure zero data retention when processing third-party API payloads, payloads must be transformed on the fly without ever being written to a database, disk, or durable queue.
• No Integration-Specific Code: Hardcoded provider logic (if provider === 'hubspot') introduces custom code vulnerabilities. Logic should be handled via declarative configuration.
• Client-Side Retry Management: The integration layer must not buffer payloads to retry failed requests. Instead, it should pass HTTP 429 Rate Limit errors directly back to your application, forcing your systems to handle the backoff.
• Stateless Webhook Fan-out: Inbound webhooks should be verified via cryptographic signatures (HMAC, JWT) in memory, transformed, and delivered via claim-check patterns rather than storing the full payload indefinitely.

The Generic Execution Engine Pattern

Truto achieves zero data retention through a generic execution pipeline. The platform contains zero integration-specific code. Instead, integration behavior is defined entirely as data: JSON configuration blobs describing how to talk to a third-party API, and JSONata expressions describing how to translate schemas.

When a request hits the unified API, the engine reads the declarative configuration, maps the unified request to the provider's native format using JSONata, securely fetches the decrypted OAuth token from an isolated vault, and executes the fetch. The response is mapped back to the unified schema in memory and returned to the caller.

sequenceDiagram
    participant App as Your SaaS App
    participant Layer as Truto Execution Engine
    participant Vault as Token Store<br>(encrypted, isolated)
    participant Vendor as Third-Party API<br>(Salesforce, Workday...)

    App->>Layer: GET /unified/crm/contacts
    Layer->>Vault: Fetch refresh token (account-scoped)
    Vault-->>Layer: Decrypted credential
    Layer->>Vendor: Native API call with OAuth
    Vendor-->>Layer: Native response (Raw JSON)
    Note over Layer: Apply JSONata mapping<br>Transform in memory
    Layer-->>App: Normalized JSON Response
    Note over Layer: Payload discarded<br>Zero data at rest

This zero data retention pass-through architecture ensures that if the integration layer is ever targeted by threat actors, there is no historical customer payload data to steal. The properties this delivers map almost one-to-one onto NIS2 Article 21 requirements: supply chain risk minimization, incident response scoping, data minimization, and a clean architectural story for right-to-audit clauses.

Handling Rate Limits Without Storing Data

A common argument for stateful integration platforms is that they abstract away rate limits. They absorb HTTP 429 errors, hold the payload in a queue, and retry later.

Under NIS2, holding that payload in a third-party queue is a severe liability.

The secure architectural approach is strict pass-through of rate limit data. When an upstream API returns an HTTP 429, the integration layer should immediately pass that error back to the caller. Truto normalizes upstream rate limit information into standardized IETF headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset). This forces the calling application—where the data rightfully belongs—to manage the exponential backoff and retry logic.

// Caller never sees the access token
const response = await truto.unified.crm.contacts.list({
  integratedAccountId: 'acc_9f2...',
  pageSize: 100,
})
 
// Under the hood:
// 1. Token lookup, scoped to this account only
// 2. Refresh if within TTL window (no caller involvement)
// 3. Native API call, response transformed in-memory
// 4. Rate-limit headers normalized per IETF spec and passed through
if (response.headers['ratelimit-remaining'] === '0') {
  // Caller handles backoff. The platform does not silently retry on 429.
  await sleep(Number(response.headers['ratelimit-reset']) * 1000)
}

This approach ensures that hiding rate limits doesn't lead to retry storms and undefined latency, while keeping sensitive payloads out of third-party storage during backoff periods.

Managing OAuth and API Keys Securely in the Supply Chain

Authentication credentials are the most sensitive assets in your integration supply chain. If you are building integrations in-house, managing the OAuth 2.0 authorization code flow, secure token storage, and proactive token refreshes across thousands of connected accounts is a massive operational burden.

Manual token management frequently leads to race conditions. If two microservices attempt to use an expired token simultaneously, both might trigger a refresh. One succeeds, the other fails, the provider revokes the token due to suspected replay attacks, and the customer's integration breaks silently.

A defensible OAuth and key management model under NIS2 needs specific properties:

1. Per-Account Isolation: Every connected account gets its own credential blob, encrypted at rest with a key that is never shared across tenants. A compromise of one account's token cannot pivot into another.
2. Proactive Refresh Before Expiry: Tokens are refreshed shortly before their Time-To-Live (TTL) expires. This requires concurrency control (distributed locks) so two parallel workers cannot race and invalidate each other. Synchronous API calls should never block waiting for a token exchange.
3. Customer-Owned OAuth Apps: For enterprise buyers, the OAuth app registered with the vendor (Salesforce, Microsoft, Google) should be theirs, not your integration provider's. This avoids vendor lock-in and means revocation is entirely in the customer's hands.
4. No Credential Exposure: Your application code, your AI agents, and your sync jobs should never see the raw access token. The integration layer signs requests on their behalf.
5. Auditable Rotation and Revocation: Every refresh, reactivation, and failed auth event must be logged with a tamper-evident trail. NIS2 audits will ask for this evidence.

By offloading token management to a highly secure, specialized execution engine, you eliminate the risk of leaking API keys in your application logs or mismanaging refresh tokens in your primary database.

Future-Proofing Your Integration Strategy for EU Enterprise Deals

Enterprise procurement is not getting easier. As NIS2 enforcement ramps up across the European Union, the scrutiny applied to your SaaS supply chain will only intensify. If you are a senior PM or engineering leader chasing EU enterprise revenue, three architectural decisions in the next 12 months will determine whether you breeze through procurement or stall in vendor risk review:

1. Move integration logic from code to data: Hand-rolled connectors mean every API change is a code deploy, a regression test, and a potential incident. A declarative approach—where adding HubSpot, Pipedrive, or Workday is a config operation, not a code operation—shrinks your attack surface and patch cycle dramatically.
2. Pick the right architectural class of vendor: Embedded iPaaS, legacy data-syncing unified APIs, and pass-through unified APIs are not interchangeable. NIS2 favors the pass-through model. By shifting to a platform that does not store customer data, you remove the integration layer from the data residency and TPRM (Third-Party Risk Management) conversation entirely.
3. Build the audit story before the auditor asks: Map every integration to show where the credential is stored, what data flows through, what is persisted, what is logged, how a breach would be detected, and how the customer can exit cleanly. Put this in a one-page architecture document. Your sales team will use it more than you expect.

NIS2 is not a checkbox—it is a forcing function that rewards companies who make the architecturally honest choice and punishes those who bolt a sync-and-cache integration layer onto a product that wants to move upmarket. The teams that ship integrations as declarative configuration over a stateless runtime will spend less time on procurement and more time on product.