UEBA Platform Selection Criteria for Semiconductor and IP-Intensive Firms

The threat facing semiconductor firms is not a compliance category, it's design files, mask sets, and process recipes that took years and hundreds of millions of dollars to build, and whose loss might not even register until a rival's chip hits tape-out. Standard UEBA procurement checklists, built for banks and hospitals worried about PII and PHI, simply don't ask the right questions for this asset class. This piece lays out what a semiconductor or IP-intensive firm actually needs to check before signing a UEBA contract, and why the generic version of that checklist falls short.

Start with the threat itself, because it's not hypothetical. Between March and June 2025, Proofpoint Threat Research tracked three separate Chinese state-sponsored groups running targeted phishing campaigns against Taiwan's semiconductor industry, and in every case, espionage looked like the most likely motive. One of those actors, tracked as UNK_SparkyCarp, ran a credential-phishing operation in March 2025 using a custom adversary-in-the-middle framework against a Taiwanese semiconductor company it had already hit once before, back in November 2024. Collusion — meaning adversaries coordinating across different points in the supply chain — is increasingly recognized as a distinct and growing risk category, not a footnote.

Then there's the insider dimension. North Korean insider-threat operations made headlines through 2024, and they forced a shift in how firms think about hiring: the person applying for a design role might not be an opportunistic employee who later turns bad, but someone placed there from the start. Broader numbers back up the scale of the problem: 83% of organizations reported insider attacks in 2024, and the average annual cost of resolving insider incidents hit $17.4 million per organization in 2025, up 109% since 2018. Those are general enterprise figures. For a firm sitting on process node IP that shapes a country's military and commercial technology trajectory, the real exposure runs higher still. When the adversary might be a state actor working through a trusted badge-holder, and the asset at stake can move a nation's chip roadmap, "standard enterprise" procurement criteria stop being adequate on day one.

How IP exfiltration actually unfolds in semiconductor environments, and the patterns UEBA must be built to catch

Four documented cases show what detection actually has to look like in this industry, and none of them fit the volume-and-signature model that older tools were built around.

Take the storage-device pivot. A former Intel software engineer, Jinfeng Luo, allegedly downloaded around 18,000 sensitive files in late July 2024, just days before his termination. Intel's internal data-loss prevention tooling caught the first attempt, a transfer to an external hard drive, and blocked it. Five days later, Luo plugged in a different device and got the files out, many of them marked "Top Secret." The lesson isn't subtle: a block list built around specific devices fails the moment someone swaps hardware. What was needed was a system tracking the person's behavior across devices, not a rule about one USB drive.

A second pattern shows up in the Apple Vision Pro case, settled in March 2026. Engineer Di Liu downloaded thousands of confidential files to his personal iCloud account in the days before leaving Apple for Snap. The failure wasn't a lack of cloud visibility in general, it was a failure to flag bulk personal-cloud activity during the exact window when departing employees are statistically most dangerous: the weeks right before they walk out the door.

A third pattern is competitor recruitment at nation-state scale. A former Samsung executive was caught stealing trade secrets to help build a competing fab in China, which is the same competitor-poaching dynamic playing out in xAI's 2025 case against former engineer Xuechen Li, accused of taking Grok trade-secret files with him on his way to a job at OpenAI. Different company, different chip, same shape: valuable IP walking out the door toward a rival who wants the shortcut.

Fourth, and maybe most important for evaluation purposes, is the slow drain. One analysis of exfiltration timing found the first measurable warning signs, directory lookups, file-access mapping, show up roughly 200 days before an employee's departure, well before any dry-run copy or live transfer. Documented exfiltration vectors break down with personal cloud storage responsible for 22.7% of incidents and removable media for 15.6%, but in a semiconductor environment, the channel matters less than whether the platform can catch the sequence leading up to it. A separate analysis found a 720% spike in risky exfiltration activity in the run-up to layoff announcements, which means restructuring and fab transitions are themselves a monitoring inflection point, not just an HR event.

One more vector is still forming. Gartner wrote in November 2025 that conventional DLP "cannot effectively manage GenAI data loss risks, including exposure via encrypted traffic, intent blindness, and shadow AI." Design engineers pasting RTL snippets into an AI coding assistant or synthesis tool are, right now, a blind spot in most deployed platforms. Each of these four archetypes points to a specific requirement: continuity across a timeline, monitoring that doesn't care which device is plugged in, visibility into cloud apps, and behavioral escalation tied to the approach of a departure date. Those requirements are what the rest of this piece is built around.

Where generic UEBA evaluation frameworks break down for this sector

Most UEBA evaluation guides are written for credential misuse, lateral movement, and known-bad signature bypass. All of that is real. None of it is the dominant way semiconductor IP actually walks out the door.

Three gaps show up again and again. First, file-type blindness: generic frameworks treat "sensitive data" as a compliance category, meaning PII, PCI, PHI, and little else. GDSII layout files, RTL source, process recipe parameters, and mask data don't fit into any of those buckets, so a platform tuned for regulatory data types can miss the most valuable assets in the building entirely, simply because nobody taught it what those assets look like.

Second, most standard evaluation criteria assess anomaly detection at a single point in time, one session, one event, one score. The Intel and Apple cases both required catching a pattern that unfolded across days or weeks, including, in Intel's case, a pivot that happened after an initial block. A system built around single-event scoring would have seen nothing wrong until the second, successful transfer, because the first, blocked attempt didn't count as a data point in its risk model.

Third, offboarding gets treated as an IT workflow, not a detection state. Access revocation tickets get filed, badges get deactivated, and that's usually where the security posture stops. But the evidence above shows exfiltration behavior often begins 200 days before someone leaves and spikes hard around layoff announcements. A platform has to treat an approaching departure, or a wave of layoffs, as a state that changes alert thresholds automatically, not an event that triggers an access-management checklist after the fact.

The Intel case is worth returning to here because it's such a clean illustration of legacy DLP's structural problem: the rule blocked device A and said nothing about device B, because the rule was written about the device, not about the person's behavior. Traditional DLP evaluates data at a single moment, disconnected from who's behind it or what pattern they're in the middle of.

One more number matters for how a platform gets tuned. The Ponemon Institute's 2025 Cost of Insider Risks report put the share of insider-related incidents stemming from negligence, not malice, at a majority. That's relevant for evaluation because a platform calibrated only to catch deliberate theft will drown security teams in false positives for accidental policy slips, while still missing the behavioral escalation that actually separates a careless mistake from a calculated exfiltration. With the gaps named, the rest of this piece turns to the criteria built to close them.

Criterion 1: behavioral baselining that understands IP-class assets, not just data movement volume

The question to ask a vendor is simple to state and hard for most platforms to answer well: does the baselining engine know the difference between an engineer pulling from the GDSII library they own and one reaching into a process node spec that belongs to a project they're not on?

A few things to check. Peer-group baselining needs to work by role, project team, and access tier, not just department or job title, so that lateral movement into an adjacent project registers as strange even when the credentials are technically valid. Entity classification needs to map onto the firm's real IP taxonomy: design files, simulation outputs, fab recipes, mask sets, NDA-bound partner data, rather than a pre-built compliance schema borrowed from a healthcare or finance deployment. Temporal baselining matters too: a mass file pull during a tapeout sprint means something different from the same volume of activity on a Sunday three weeks after the project closed, and the platform needs to know the difference. And it's worth asking directly whether the system supports unsupervised learning to surface patterns nobody thought to write a rule for, versus requiring the security team to define every detection scenario up front.

Watch for a specific red flag in vendor demos: platforms that lead with "detecting large file transfers" as their headline IP-theft capability. Volume without content classification and project context is exactly the legacy DLP model that the Intel case illustrated doesn't catch every exfiltration path. A good practical test during procurement: ask how the platform would baseline and alert on a physical design engineer who starts pulling foundry process parameters that belong to a competing internal program. If the answer involves someone writing a rule, the baselining isn't behavioral, it's a list dressed up as machine learning.

Criterion 2: detection continuity across the full behavioral timeline, not individual events

A single event is almost never the actual risk. The Intel case had a blocked first attempt, a five-day gap, and a successful second attempt on different hardware. A system that treats those as three unrelated log entries only ever sees a successful transfer, and by then it's too late to do anything but forensics.

Check whether the platform keeps a persistent, time-ordered activity record for each user across sessions, devices, and applications, rather than correlating logs within a single session and calling it done. Check whether a blocked action, a DLP block or an access denial, gets retained as a signal that raises that user's risk score going forward, instead of disappearing once the block succeeds. Ask whether the platform can trace the reconnaissance-to-exfiltration sequence: directory lookups, then file-access mapping, then a dry-run copy, then the live transfer, each step innocuous on its own, damning as a sequence. Ask how far back the context window goes, too: a platform with a short history window will struggle to surface a pattern that started 200 days before someone's last day. And ask specifically how the system handles a device pivot: does it connect a failed transfer on one device to a successful one on a different device five days later, or does it file them as separate, unrelated events?

It reportedly takes an average of 81 days to detect and contain an insider incident, a number that reflects, at least in part, the gap between when the behavior actually starts escalating and when a point-in-time detection model finally trips. A platform with real timeline depth can shrink that gap substantially. When evaluating vendors, ask for a demo of a case where every individual action was policy-compliant and the sequence itself was the violation. If the demo needs a rule violation somewhere in the chain to fire an alert, what's being shown is not timeline analysis.

Criterion 3: coverage across the specific channels semiconductor IP actually moves through

Match the coverage question to the channels the real cases used. Removable media, as in the Intel case, means the platform has to watch USB and external storage attach events behaviorally, not maintain a list of blocked device IDs. Personal cloud storage, as in the Apple case, means the platform needs to ingest signals from the firm's sanctioned cloud tools, whatever those are, and flag sync activity toward personal accounts specifically; recall that personal cloud storage accounts for 22.7% of documented exfiltration incidents. Email forwarding rules, a common setup step before someone leaves, means mail-rule creation itself needs monitoring, not just outbound attachment size. Collaboration tools blur the line between work and personal use constantly, and exfiltration through chat and workspace platforms is a documented, growing pattern worth asking about directly. And generative AI tools need an explicit answer from the vendor, even an honest "not yet fully covered," given the industry observation that conventional DLP can't handle GenAI-related data loss, including encrypted traffic and shadow AI use.

Semiconductor environments add integration requirements that don't show up in a generic enterprise stack. EDA tool environments, meaning the Cadence, Synopsys, and Mentor toolchains engineers actually work in daily, generate file-access events that a generic endpoint agent may not parse correctly at all. Ask directly whether the vendor has real experience with EDA telemetry or a documented path to get there. Separately, PDK repositories and foundry NDA-bound data often sit in isolated network segments or fully air-gapped environments, so the platform needs to run there without losing detection fidelity, not just claim on-prem compatibility on a slide.

The most useful procurement exercise here is blunt: map out where the firm's IP actually lives and how it actually moves, then check that map against each vendor's confirmed data source connectors. Any gap in that mapping is a gap in detection, no matter how sophisticated the underlying model is.

Criterion 4: workforce-event and offboarding states as first-class detection triggers

The pre-departure window is, by a wide margin, the highest-risk period a firm will ever face with a given employee, and the numbers back that up from more than one direction. One analysis found a 720% spike in risky exfiltration activity right before layoffs are announced. Exfiltration behavior often starts around 200 days before someone actually leaves, usually with reconnaissance rather than a straight copy. A 2023 Beyond Identity survey found 89% of former employees still had access to at least one application from a past employer, only 48% of businesses even knew former employees retained that access, and 20% had suffered a data breach as a direct result.

So the checklist here is about whether HR events actually change the platform's behavior in real time. Does it accept feeds from HR systems and use a resignation notice, a performance improvement plan, or a termination-pending flag to automatically tighten that person's alert thresholds, as an integrated system state rather than a manual override someone has to remember to flip? Can it run a retrospective look-back the moment a resignation comes in, surfacing the prior 30, 60, or 90 days of that person's activity for review in light of the new context? Does it watch for the pre-departure signals from the cases above as a coordinated pattern, meaning bulk downloads, new forwarding rules, USB attach events, personal cloud syncing, and a burst of external email, together, rather than as five separate low-priority alerts nobody connects? And does it check its own work after departure, confirming that access was actually revoked and flagging any activity from an account that should be dead?

None of this works if it's a manual handoff between departments. Effective offboarding detection needs the platform sitting between HR, IT, and security as the thing that actually connects them. A system that needs someone to file a ticket before it changes its monitoring posture is a gap waiting for someone to walk through it.

Criterion 5: data residency, air-gap support, and the privacy

<!-- Section intentionally left as specified by structure requirement -->