Your SOC Watches Your Employees. It Doesn’t Watch Your Vendors.

Third-party involvement in breaches doubled from 15% to 30% in a single year — the largest single-year shift ever recorded by the Verizon 2025 Data Breach Investigations Report. A supply chain compromise now costs an average of $4.91 million and takes 267 days to identify and contain, the longest lifecycle of any breach vector IBM tracks. In the Philippines, every organization that suffered a third-party-linked breach in the past year was compromised through a vendor account, not a direct attack on their own perimeter.

Manufacturing is now the most targeted industry worldwide and accounts for 40% of all cyberattacks in Asia-Pacific. Most of the manufacturers we work with in Thailand have a SIEM, a SOC, and reasonable detection coverage on their own users and endpoints. Almost none of them have a rule that fires when an equipment vendor’s VPN account logs in at 2am from a country they’ve never connected from before.

That’s not a procurement gap. It’s a detection gap — and it exists because SOC tooling was built to watch employees, not the accounts your organization hands out to everyone else.

---

Why This Is a Blind Spot, Not an Oversight

A typical SOC baseline is built around employee behavior: this user normally logs in from Bangkok between 8am and 7pm, accesses these three systems, and never touches the finance server. Deviations from that baseline generate alerts.

Vendor and contractor accounts don’t fit that model, for three structural reasons:

They’re intentionally irregular. A vendor’s support engineer might log in once a quarter for a firmware update, at whatever hour suits their timezone, from whatever network they happen to be on. There’s no stable baseline to deviate from — which means most behavioral detection either ignores these accounts or generates so much noise on them that analysts learn to dismiss the alerts.

They’re invisible in the identity layer. Most organizations provision a vendor account the same way they provision an employee account — same AD group, same naming convention, sometimes the same shared login across multiple vendor staff. Nothing in the identity system distinguishes "this is a third party with time-boxed, scope-limited access" from "this is our own engineer."

Nobody owns deprovisioning. Bitsight’s 2026 research found only one in three organizations continuously monitors all of their third-party relationships for cyber risk — most rely on periodic assessment cycles that leave multi-month visibility gaps. A vendor contract ends, the invoice stops, and the VPN credential that was issued eighteen months ago quietly keeps working because no single team is responsible for closing it.

This is the same identity debt problem we’ve written about before — every account without a centralized owner becomes an account nobody remembers to remove — except vendor accounts carry an added risk: the organization has far less control over how the credential is stored and used on the vendor’s end.

---

Two Attack Surfaces, Same Root Cause

IT vendors: the MSP and SaaS integration path

Managed service providers, billing platforms, and SaaS integrations routinely hold standing credentials or API keys with broad access into core systems. When one of those providers is compromised, the attacker inherits legitimate, already-trusted access — no phishing, no exploit, no alert that looks like an intrusion because technically it isn’t one yet.

OT vendors: the equipment maintenance path

We’ve covered this pattern in more depth in our piece on factory floor security, but it’s worth restating here: a huge share of industrial remote-access risk comes from a VPN concentrator sitting on the OT segment with credentials the equipment vendor set up years ago and nobody has rotated since. That path bypasses the IT/OT boundary entirely, because it was built as a legitimate maintenance channel, not an attack path — until it’s used as one.

Both surfaces share the same underlying failure: the access is real, authorized, and completely untracked as a distinct risk category.

flowchart TD
  A["Vendor / Contractor Account"] --> B["Provisioned like an employee account"]
  A --> C["No time-boxed scope"]
  A --> D["No dedicated risk tier"]
  B --> E["Blends into normal auth logs"]
  C --> F["Access persists after contract ends"]
  D --> G["No correlation rule treats it differently"]
  E --> H["SOC sees a valid login, not a risk event"]
  F --> H
  G --> H
  H --> I["Breach detected 267 days later, if at all"]

---

What Actually Closes the Gap

Monitoring vendor access isn’t a bigger version of monitoring employee access — it requires treating third-party identity as its own category, end to end.

1. Tag vendor identity at provisioning, not after an incident. Every vendor, contractor, and integration account needs a distinguishable identity attribute — a dedicated OU in your directory, a naming convention, or an SSO group specific to third parties. Without this, no downstream detection rule can treat vendor access differently, because nothing tells the SIEM which accounts are vendors in the first place.

2. Build correlation rules around vendor risk tiers, not generic anomaly baselines. Rather than trying to learn a "normal" pattern for an account that logs in twice a year, write explicit rules: any vendor account access outside a pre-approved maintenance window is high severity by default. Any vendor account touching a system outside its documented scope is high severity by default. The rule doesn’t need to learn behavior — it needs to enforce scope.

3. Time-box access at the source. The most effective fix is architectural, not detective: vendor VPN and remote-support credentials should expire automatically unless explicitly extended for an active maintenance window. A detection rule that catches an out-of-window vendor login is good. A credential that simply doesn’t work outside that window is better.

4. Route vendor-tagged alerts through a separate playbook. Once accounts are tagged, a SOAR layer can apply a distinct escalation path — vendor account anomalies should page a human by default rather than auto-close, since the volume is low and the potential blast radius is high. This is the same triage-assist-before-auto-close discipline that applies to alert fatigue generally — it’s just applied to a category where false negatives are far more expensive than false positives.

5. Make deprovisioning a scheduled review, not a hope. Tie every vendor account to a contract end date at creation time, and put an automatic 90-day review on any vendor credential with no matching active contract. This is the control most third-party breaches trace back to in hindsight — not a sophisticated attack, just a credential nobody closed.

flowchart TD
  A["Vendor onboarding"] --> B["Tag identity: vendor OU + scope + expiry"]
  B --> C["Define access window"]
  C --> D["Correlation rule: any access outside window = high severity"]
  D --> E["SOAR: vendor alerts route to analyst, no auto-close"]
  E --> F["Contract ends"]
  F --> G["Scheduled deprovisioning review"]
  G --> H["Credential revoked at source"]

---

How simpliSOC Handles Vendor Access

simpliSOC runs on Wazuh for detection, DFIR-IRIS for case management, and Shuffle for automation — the same stack behind our other SOC deployments. Extending it to cover vendor access doesn’t require new tooling, just a different rule set:

• Vendor and contractor accounts are tagged at the identity layer (AD OU or SSO group), so Wazuh’s correlation rules can apply a distinct severity baseline to them instead of the general employee baseline
• Access-window rules are written explicitly per vendor contract — any authentication event outside the agreed maintenance window is flagged as high severity regardless of source IP reputation
• Shuffle playbooks route vendor-tagged alerts directly to an analyst with contract and scope context pre-attached, rather than folding them into the general auto-triage queue
• IRIS cases involving vendor accounts are tagged separately, so quarterly reviews can pull every vendor-related incident without digging through the general case log

None of this replaces the vendor risk assessment your procurement or GRC team should already be doing before a contract is signed. It closes the gap between that assessment and what your SOC actually sees once the vendor has live access — which, per the Verizon data, is where nearly a third of breaches now originate.

Want a second opinion on how much of your vendor access is actually visible to your SOC today?
Talk to the simpliSOC team → hello@simplico.net

---

FAQ

Isn’t vendor risk a procurement problem, not a SOC problem?
Both. Vendor risk assessment before signing a contract (financial stability, security posture, certifications) is a procurement and GRC function. What happens after the contract is signed — whether that vendor’s actual access is monitored, scoped, and revoked on schedule — is a SOC function. Most breaches involving vendors happen well after the assessment phase, during ordinary operation of access nobody is watching closely.

We use a lot of SaaS tools with API integrations. Does this apply to us even without on-site vendors?
Yes, arguably more so. An API key with broad scope is functionally the same risk as a vendor VPN account — standing, authorized access that doesn’t fit a normal user behavior baseline. The same principles apply: tag it, scope it, time-box it where possible, and route anomalies through a distinct alert path.

How do we find out how much vendor access we currently have?
Start with an audit, not a tool purchase: pull every AD/SSO account not tied to a current employee, every active API key, and every VPN credential, and match each one against an active contract. The gaps that show up — accounts with no matching contract — are usually the first ones worth closing.

Does this apply to OT vendor access differently than IT vendor access?
The principle is identical — tag it, scope it, time-box it, alert on deviation — but OT vendor access carries higher stakes because a compromised equipment vendor credential can reach production systems directly. See our factory floor security piece for how to extend detection into the OT segment itself.

Will this slow down legitimate vendor support requests?
Not if the access window is pre-approved rather than requested reactively. Most organizations that implement time-boxed vendor access schedule maintenance windows in advance as part of the support contract, so the access simply exists when it’s needed and doesn’t when it isn’t — no extra approval step in the moment.

We’re a smaller organization. Is this worth the effort before we have a full SOC?
Yes — arguably it’s easier to get right early. Tagging vendor identity and setting expiry dates at the point of onboarding costs almost nothing. It’s much harder to retrofit onto years of accumulated, untagged vendor accounts than to build in from the start.