The IP Transfer Chain: Why Your EOR Might Own Your Code
In cross-border employment, "Work for Hire" does not always apply. We explain why the "Employee → Local EOR → Master EOR → Client" chain often breaks, leaving your IP vulnerable.
"All intellectual property created by the Employee shall be the sole and exclusive property of the Company."
If you are a US company, you are used to seeing this clause. It is the standard "Work for Hire" doctrine. It is simple, powerful, and automatic.
But when you hire a developer in Germany, France, or Brazil through an Employer of Record (EOR), that clause might be legally worthless.
Intellectual Property (IP) laws are territorial. The US concept of "Work for Hire"—where the employer automatically owns everything the employee creates—does not exist in many civil law jurisdictions. Instead, these countries prioritize the rights of the *creator*.
This creates a massive, often overlooked risk in global hiring: **The IP Transfer Chain.**
## The Relay Race Problem
In a direct employment scenario, IP transfer is a simple handoff: Employee → You.
In an EOR scenario, it is a relay race with multiple runners. And if any runner drops the baton, you lose.
1. **Runner 1 (The Creator):** The software engineer in Berlin. 2. **Runner 2 (The Legal Employer):** The EOR's local German entity. 3. **Runner 3 (The Master EOR):** The US/UK entity you signed a contract with. 4. **Runner 4 (The Client):** You.
For you to own the code, the IP rights must successfully jump from Runner 1 to Runner 2, then to Runner 3, and finally to Runner 4.

Here is where the baton drops.
## 1. The "Moral Rights" Hurdle
In many European countries (like France and Germany), an author has "Moral Rights" (*droit moral*) that are **inalienable**. They cannot be sold or transferred. These include the right to be attributed as the author and the right to prevent "derogatory treatment" of the work.
While economic rights (the right to sell the software) *can* be transferred, the contract must be extremely specific. A generic "all IP is transferred" clause often fails because it is too broad.
If the EOR's local employment contract with the developer is a copy-paste template that does not specifically address local IP assignment laws, the transfer from Runner 1 to Runner 2 never happens. The developer still owns the code.
## 2. The Aggregator Gap (Broken Chain of Title)
This risk explodes when you use an "Aggregator" EOR (see our article on [Direct EOR vs. Partner Networks](/insights/direct-eor-vs-partner-network-risks)).
In an Aggregator model, Runner 2 (the local employer) is a third-party vendor, not the EOR itself.
Does the Master EOR have a watertight IP assignment agreement with that local vendor in Vietnam? Or is it a loose partnership agreement?
We have seen cases where the Local Partner claimed *they* owned the IP because the Master EOR failed to pay an invoice. The client (Runner 4) was left holding a contract with the Master EOR (Runner 3) that promised IP ownership, but the Master EOR never actually received the IP from the Local Partner (Runner 2).
You cannot transfer what you do not possess.
## 3. The "Pre-Existing IP" Trap
Developers rarely write code from scratch. They use open-source libraries, personal snippets, and previous work.
A strong direct employment contract forces the employee to declare "Prior Inventions" to avoid contaminating your codebase.
But in an EOR model, you are not the one signing the employment contract. The EOR is. Does the EOR's standard template include a robust Prior Inventions assignment? Does the EOR's HR team in the Philippines understand the nuance of open-source license compatibility?
Often, the answer is no. The EOR cares about payroll compliance, not software licensing.
## How to Protect Yourself
You cannot rely on the standard EOR Master Services Agreement. It is a promise to give you IP, not proof that they have it.
1. **Demand a "Direct Assignment" Deed:** Even though you are not the employer, you can ask the employee to sign a separate, direct IP assignment deed in your favor. This creates a direct link between Runner 1 and Runner 4, bypassing the messy middle. (Note: Check local labor laws to ensure this does not trigger "co-employment" risks, but for IP, it is often worth the calculated risk). 2. **Audit the Local Contract:** Do not just read the MSA you sign. Ask to see the *actual employment contract* the developer signs in their home country. Have your IP counsel review the assignment clause. 3. **Verify the Chain:** If using an Aggregator, ask for proof of the back-to-back IP assignment between the Master EOR and the Local Partner.
Your code is your company's most valuable asset. Do not leave its ownership to a game of telephone.