Most security programs assume the primary risk is “someone breaks into our app.” In practice, many of the most damaging incidents begin one step to the side: a vendor, integration, contractor laptop, iPaaS connector, ETL job, or “temporary support” exception that quietly became permanent. That is the “side door” problem: you can harden your front door and still lose everything through someone else’s access path.

This post extends the earlier “side doors” article into an actionable checklist you can apply to any third-party integration—whether it is a BI tool, a managed service provider, a customer-support workflow, or a data pipeline. 

Why this matters now

Third-party involvement is not a niche edge case anymore. Verizon’s 2025 DBIR executive summary reports that the share of breaches involving a third party doubled from 15% to 30% year-over-year, and highlights how credential reuse and leaked secrets can create long-lived exposure (including a 94-day median time to remediate leaked secrets discovered in a GitHub repository). 

Recent “platform-adjacent” incidents have also reinforced the same lesson: attackers do not need to compromise the core platform if they can obtain valid credentials and reuse them at scale (especially when MFA, rotation, and network allowlists are absent).  A single third-party software flaw can also propagate across hundreds of downstream organizations. 

The goal: make stolen vendor access boring

In the original side-doors post, the core design objective was: stolen access should have minimal value. The three levers are:

1. Reduce capability (limit what attackers can read/do)

2. Shrink time (limit how long access works)

3. Degrade usefulness (make exfiltrated data less valuable and tampering noisier)

Everything in the checklist below maps to one or more of those levers.

Step 1: Classify the integration before you secure it

Not all integrations are the same. Treat them as distinct threat models:

• Support / SRE access (humans, elevated roles, “break-glass,” console access)

• API-to-API integrations (service principals calling narrow endpoints)

• Data movement (ETL, iPaaS, BI tools, warehouse sync, backups/exports)

• Embedded client components (SDKs, browser extensions, plug-ins)

• Managed services (vendors operating infrastructure, monitoring, incident response)

Your controls should be strictest for data movers and privileged human access, because that is where “wholesale compromise” typically happens.

Vendor-safe Integration Checklist

Use this as a gated intake and a periodic review (quarterly is a practical cadence). If a vendor cannot meet a “must-have,” the remediation is architectural: reduce scope, broker access, or isolate data behind a safer boundary.

A. Integration intake and data minimization (start here)

• Document the purpose: What business outcome does this integration enable? What breaks if it is off for 72 hours?

• Define the minimum viable dataset: Exactly which fields, tables, and time ranges are required?

• Default to “derived over raw”: Prefer aggregates, tokenized identifiers, and precomputed views over raw PII/PHI.

• Separate “operate” vs “analyze”: If the vendor is for analytics, it should not need write access—ever.

B. Identity: eliminate shared credentials and long-lived keys

• No shared accounts (especially not “vendor-admin@”).

• Prefer workload identity (OIDC-based federation) over static secrets for machine-to-machine access.

• For human access: enforce SSO + phishing-resistant MFA (FIDO2/hardware-backed where possible) and device posture checks; session tokens are a primary target in modern attacks. Google Cloud

• Segregate environments: separate identities for dev/test/prod; no cross-environment credentials.

C. Authorization: “least privilege” must be provable

• Scope by function, not convenience: do not grant schema-wide or account-wide roles because “it’s easier.”

• Use purpose-built views/endpoints (not direct database access) wherever possible.

• Constrain by tenant/customer: row-level security or per-tenant boundary controls.

• Deny bulk by default: rate limits, pagination caps, export limits, and query allowlists where feasible.

• Read-only unless explicitly justified: any write capability should be narrowly bounded and auditable.

D. Token and secret hygiene: stop “token sprawl”

Token sprawl and long-lived secrets are a recurring failure mode.

• Short-lived access tokens; refresh via tightly controlled flows.

• Rotation and revocation are operationalized: you have a documented kill switch and you test it.

• Secrets never appear in logs: sanitize headers, query strings, and exception traces.

• CI/CD scanning for secrets; prevent merges that introduce credentials.

• Constrain token usability: bind to workload identity, network context, and specific scopes (where supported).

E. Data movement controls: prevent shadow copies and uncontrolled exports

Shadow copies are where monitoring and policy typically fail.

• No unmanaged staging buckets: all staging is encrypted, access-logged, and lifecycle-managed (auto-delete).

• Prefer pull over push: have your system publish a sanitized export that the vendor retrieves, rather than granting the vendor credentials to crawl your systems.

• Watermark and honeytoken sensitive exports: detectable canaries turn silent leakage into an alertable event.

• Minimize retention: if data is replicated into a vendor system, enforce contractual and technical deletion SLAs.

F. Network and access path containment

The Snowflake campaign writeup highlights how missing MFA and missing network allowlists amplify credential theft.

• Private endpoints where possible; otherwise strict IP allowlists and mTLS.

• Egress controls on your side (and require them on the vendor side for privileged workflows).

• Broker all vendor access through an integration gateway you control (policy enforcement point + audit).

G. Monitoring that distinguishes “normal vendor work” from exfiltration

• Behavioral baselines per integration principal (schemas touched, query volume, time-of-day, export frequency).

• Correlate with approvals: access should map to a ticket, change request, or support case.

• Alert on “newness”: new tables, new regions, new ASNs, new client fingerprints.

• Detect bulk-read patterns: repeated wide scans, sequential ID walking, abnormal export sizes.

H. Incident response: assume you will need to shut the side door fast

• One-button disable: revoke tokens, disable the integration identity, and block network paths.

• Prewritten playbooks: “Vendor credential theft,” “Vendor compromise,” “Unexpected export event.”

• Blast radius computation: you can answer, within hours, “what data could this integration access?”

I. Contract and governance guardrails

Technical controls matter most, but contracts prevent “policy drift.”

• Security addendum with teeth (MFA requirements, device posture, breach notification SLAs, subcontractor controls).

• Right to audit for high-risk access.

• Evidence requirements: SOC 2 / pen test summaries and SBOMs for delivered software.

Practical patterns that work in real stacks

If you want to implement the checklist without a full replatform, these patterns are effective:

1. Integration Gateway Pattern
   All vendor calls terminate at your gateway (authn/z, schema/field filtering, rate limiting, logging). Vendors never touch the database directly.

2. PII Vault Pattern
   PII/PHI moves behind a narrow service boundary. Most vendors see surrogate IDs; only a minimal set of internal workflows can resolve them.

3. Sanitized Export Pattern
   Vendor gets a curated, time-bounded export product with enforced retention and embedded canaries—rather than standing access into production systems.

4. JIT Support Access Pattern
   “Break-glass” becomes time-boxed elevation with recorded sessions and automatic revocation.

Where architecture changes the outcome

Controls help, but the structural problem remains: many conventional architectures centralize plaintext access in places vendors can eventually reach. The earlier post described the alternative design goal—constraining blast radius through encrypted runtime and per-package isolation—so that even “valid” access cannot become a bulk dump.

That is why BrunnrDB emphasizes package-centric encryption, client-side decryption for the briefest possible time, immutable/verifiable lineage, and independent per-package keys—so a vendor breach cannot automatically become your breach.

Quick scorecard (use this in vendor reviews)

If you can answer “yes” to these, you are doing containment, not just compliance:

• Could you disable the integration in minutes?

• Does the vendor have only the minimum data and no schema-wide permissions?

• Are vendor credentials short-lived and rotated, with no static secrets?

• Can you prove there are no uncontrolled shadow copies?

• Would stolen access yield only a narrow, auditable slice—not your whole dataset?