Microsoft Patents a System That Locks Private Data to Specific Apps, Not Just Users
Logging in with the right username used to be enough to get into a company's private systems. Microsoft's new patent wants to add a second layer: even if you are who you say you are, the specific app you're using also has to pass a check.
What Microsoft's per-app access control actually does
Ever logged into a work system and wondered what's actually stopping someone from using your credentials in a different app to sneak into the same files? That gap is exactly what this patent is trying to close.
Microsoft's approach would tie access to private resources (think internal company databases or corporate file servers) to three things at once: who you are, which device you're on, and which specific program is making the request. So even if an attacker stole your password, they couldn't get in from an unauthorized app or a copycat tool pretending to be a legitimate one.
The system works through a small security agent running on your device. That agent checks whether your identity and the app's identity together satisfy a policy, then passes both to a central server for a second confirmation. Only if both checks pass does your device get access to the resource.
… utilize the security client to provide the first identity and the second identity to a server that enforces a second security policy, the second security policy specifying whether a combination of the first identity and the second identity is authorized to access a resource …
Translation: The device sends both user and app identities to a server to check if that specific combination is allowed to access a resource.
How the device, user, and process identities stack up
The patent describes a client device that carries two distinct identities at once: a user identity (tied to the person logged in) and a process identity (tied to the specific software running on the device).
Process identity is defined carefully. It can be established by any combination of:
- The process name and version
- A code-signing signature (a cryptographic stamp the software's publisher bakes in, proving the app hasn't been tampered with)
- A thumbprint (a short fingerprint derived from that signature)
- The publisher's name
A local security client (software running on the user's device) performs a first-pass check: does this user-plus-process combination satisfy a local security policy? If yes, it packages both identities and sends them to a remote security engine (a server run by the organization) for a second, authoritative check against the network-wide policy.
The patent also references ZTNA (Zero Trust Network Access, a security model that treats every access request as unverified until proven otherwise) and SASE (Secure Access Service Edge, a cloud architecture that bundles network and security services together). Those are the industry frameworks this system would plug into. The end result: the policy engine can say 'User A on Device B running App C with signature S may access Resource D' and refuse anything that doesn't match all four.
For example, a security policy may indicate user A, using computing device B executing process C with process signature S (e.g., a signing signature thumbprint, etc.) may access private resource D.
Translation: Access rules can require a specific user, device, and verified app program to all line up before opening a private file.
What this means for corporate network security
For companies running remote or hybrid workforces, the perimeter-based model (trust everyone inside the building, block everyone outside) has been dead for years. The replacement is zero trust, where every access request has to prove itself. This patent extends that idea down to the software level: your VPN client is approved, but a rogue script running on the same machine is not, even if you're the one who launched it.
In practice, this kind of control would let an IT team say that only the official version of, say, a payroll app can reach the payroll server, and any other tool (including an outdated or modified copy) gets blocked automatically. Microsoft's run of enterprise-security filings suggests the company is pushing this kind of granularity deep into its cloud and identity platform stack.
The 361st Microsoft filing in our Microsoft coverage since May follows work like the AI slide presenter and the form auto-fill system.
Claim 1 is fairly broad. It covers any client device that checks a combination of user identity and process identity against two security policies, one local and one server-side. It does not require a specific signing algorithm, a specific network protocol, or even a specific way of identifying the process (name, signature, thumbprint, and publisher are all listed as alternatives in the abstract, not requirements in the claim).
That breadth has real consequences. A claim this wide could, if granted, cover a significant slice of how zero-trust network clients already work today. Many enterprise VPN and endpoint-detection tools already make access decisions based on both the logged-in user and the process requesting the connection. Whether prior art in that space narrows the claim is a question for examination, but the surface area being claimed here is large.
For everyday users, the underlying idea is genuinely useful and addresses a real gap. The filing's strategic value to Microsoft probably lies less in any single technical trick and more in staking a broad claim over the two-identity check pattern as zero-trust adoption accelerates across enterprise IT.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
7 drawing sheets from US 2026/0261561 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →