Somewhere in your tenant there is a SharePoint site from a project that shipped eighteen months ago. A foundry contact and two engineers from an IP vendor still have access to it. The person who set it up has since left the company. Nobody has looked at that site since the last milestone, and nobody will – until the day someone asks who could see the design files inside it, and the honest answer is that you would have to go and check.
That is what a semiconductor IP leak usually looks like. Not a break-in. Not a nation-state operator. A guest account that outlived its purpose, sitting quietly on a folder full of netlists and sign-off reports. When people picture losing design IP, they picture an attacker; the reality is closer to leaving a filing cabinet unlocked in a building you no longer occupy. Semiconductor IP protection is far more a matter of governing who can still open your files than of stopping a hacker at the door.
The collaboration is unavoidable. The governance under it usually isn’t there.
Designing a chip is a team sport played across companies. Foundries, IP and PDK partners, materials and equipment vendors, OSAT providers, customers – the confidential work moves among all of them, every day. Most of that movement happens on the tools you already have: Teams and SharePoint for the internal design, verification, and product teams, guest access for the outside partners, and a mix of email, vendor portals, and one-off data rooms for everything else.
None of that is wrong. Teams and SharePoint are the right place for the work to live. The problem is what is missing underneath: a layer that decides, and keeps deciding, who should still have access to what. Without it, sharing is a one-way ratchet. Access goes out easily and almost never comes back, and the sites accumulate like sediment.
Six ordinary ways design IP walks out
None of these require a mistake by anyone in particular. They are just what happens when external sharing has no governance layer beneath it.
- Links that never expire. A share link created for a review stays live long after the review, the project, and sometimes the recipient are gone.
- Guests kept past the project’s end. An external partner is added for a phase of work and never removed, so their access quietly rolls forward into the next project and the one after.
- Permissions set one folder too wide. It is faster to share the library than the folder, so people do, and need-to-know erodes a little with every rushed grant.
- Orphaned sites with no owner. The owner moves teams or leaves, and the site keeps running with no one responsible for reviewing who is on it.
- No audit trail. When something does go wrong, there is no clean record of who opened, downloaded, or forwarded which file – so you cannot answer the one question that matters.
- No export-control gate. Cross-border access happens with nothing checking whether a given file should reach a given person in a given country – which, for advanced-node work under the EAR and the Foreign Direct Product Rule, is a real exposure and not a hypothetical one.
Add these up across a few hundred sites and the picture is not a fortress with one weak door. It is a building with a lot of doors, most of them propped open by someone who left.
“But we apply sensitivity labels”
You should, and they help. A Microsoft Purview label travels with the file and enforces encryption, watermarking, and view-only rules wherever the document goes. If the concern is a single file landing in the wrong inbox, labels are a good answer.
They are just answering a different question. A label protects the file; it does nothing about the room. It will not expire a guest, close an orphaned site, or notice that a partner from a finished project still has standing access to your current one. Labels are necessary. On their own they are not sufficient, because most of what leaks is not one mislabeled document – it is an accumulation of access that no one is governing. Purview protects the file. Something still has to govern the room the file lives in.
What to do instead: put a governance layer under the sharing
The fix is not to lock everything down until engineers route around you, and it is not to ship the design IP off to a third-party data room outside your control. It is to give your external collaboration the same discipline you already give your internal systems, inside the Microsoft 365 you already run.
In practice that means provisioning a governed room for each relationship – a foundry, an IP licensor, a supplier – instead of another open SharePoint site, so access starts scoped and stays that way. It means least-privilege permissions by default, and access reviews that surface stale guests and orphaned sites for someone to actually decide on, rather than waiting for an incident to find them. It means guest access that expires on its own when an engagement ends, so nobody has to remember to clean up. It means access conditioned on who a person is and where they are, so cross-border sharing has a gate in front of it. And it means an audit trail that can answer, on demand, who saw what – not one you assemble after the fact.
That combination is what Govern 365 adds to your tenant: data-room-grade governance layered onto the Entra ID, Purview, and SharePoint you already use, so the crown-jewel design IP stays put and the access around it is finally something you manage rather than something that manages itself. The semiconductor-specific version lives on the Govern 365 for Semiconductor page, and the export-control side of the same story is in why sharing a chip design is an export-control question.
The short version
Your design IP is probably not going to leave through a dramatic breach. It is going to leave through a site nobody remembers, shared with a guest nobody removed, that no one is watching. Sensitivity labels will not catch that, and a bare Teams site was never built to. Put a governance layer under your external sharing – governed rooms, least privilege, expiring guests, real audit – and keep it inside your own tenant, and the quiet leaks stop being quiet.
Frequently asked questions
Rarely a sophisticated attack. Far more often it is a governance failure that built up over time – a share link that never expired, a guest account left active after a project ended, a permission set too broadly, or an orphaned site with no owner. The files were never stolen so much as left reachable by people who should have lost access, which is why the fix is about governing access, not just hardening the perimeter.
They protect the file, which is valuable but not the whole job. A label enforces encryption and rights on the document itself; it does not expire a stale guest, close an orphaned site, or review who still has access to a given room. Most IP exposure comes from accumulated access rather than a single mislabeled file, so labels need a governance layer alongside them that manages the rooms and the guests over time.
The part that keeps deciding who should still have access. Guest sharing in a plain Teams or SharePoint site is easy to grant and easy to forget, with no automatic expiry, no routine access review, no built-in export-control gate, and no audit trail you would want to hand a customer. Adding a governance layer – governed rooms, least privilege, expiring guests, and logging – closes those gaps without moving off the platform you already use.
Start with visibility: an access review that surfaces external guests, over-broad permissions, and orphaned sites so an owner can decide what to keep. From there, tighten to least privilege, set guest access to expire with the engagement, and put those reviews on a schedule so the cleanup does not depend on anyone remembering. Govern 365 automates this against your existing SharePoint and Entra ID rather than as a separate manual project.
It matters more for standing collaboration. A deal room opens and closes; supplier and foundry collaboration runs for years, which is exactly the condition under which stale guests and orphaned sites accumulate. Governing the room – with templates, expiring guests, and scheduled reviews – turns secure external collaboration into the default state for every ongoing relationship, not a cleanup you do after something goes wrong.
Related reading
- Govern 365 for Semiconductor – foundry, IP, and export-controlled collaboration across the chip value chain, inside your own tenant.
- A Virtual Data Room for Semiconductor IP: Why Sharing a Chip Design Is an Export-Control Question – the export-control side of the same problem.
- Govern 365 Virtual Data Room – the tenant-native data room these controls are built on.
- Secure by Design – Niraj Tenany’s book on secure collaboration in Microsoft 365.
Take the next step
Book a Govern 365 semiconductor data room demo to see governed foundry and supplier rooms, least-privilege access, guest accounts that expire on their own, access reviews that surface stale sharing, and an audit trail you can hand to a reviewer – all inside a live Microsoft 365 environment. Prefer to read first? Pick up Secure by Design for the broader playbook on governed collaboration in Microsoft 365.
