Here’s a scenario: at 11:04 pm on a Tuesday, an attacker uses a phishing kit to capture a finance director's credentials. The phishing page is convincing enough that the director doesn't realize what happened. The attacker opens a VPN session, authenticates with the stolen password, and clears MFA using a real-time relay that intercepted the one-time code at the same moment. The SIEM logs a successful authentication from a known IP range. The EDR sees a valid user account. Nothing is unusual.

By 11:08 pm, they are opening budget files. By 11:40 pm, they have accessed project cost models, vendor contracts, and a folder of board presentations. At 3:14 am, an anomaly detection alert fires — the access volume across the session finally triggered a behavioral threshold. The security team is paged. 340 files have been read. In some cases, they have been copied. The investigation begins four hours after the breach started.

According to Verizon's Data Breach Investigations Report, 88 to 93 percent of breaches involve compromised credentials, a figure that has held consistent across multiple report cycles. The attack above is not sophisticated; it is the standard playbook. It’s not about how to stop the credential theft either; that is a phishing problem. The question is: what limits the damage once the attacker is inside and authenticated?

Why Valid Credentials Bypass Every Perimeter Control You Have

Perimeter security was designed around a simple assumption: untrusted identities are on the outside, trusted identities are on the inside. Firewalls, network segmentation, VPNs, and access gateways all operate on that boundary. When an attacker presents valid credentials, they do not break through the perimeter. They walk through the front door using a key that was issued to someone else.

At the moment of login, every perimeter control has already performed its function. The firewall allowed the connection. The VPN terminated the session successfully. MFA was satisfied at authentication time. The identity passed every check that perimeter architecture is designed to apply, because those checks happen once, at login, and then the session proceeds with the trust level the identity carries.

The files on the other side of that login have no independent awareness of whether the person opening them is the legitimate credential holder or an attacker. They rely entirely on the identity layer having done its job. When the identity layer has been bypassed through credential theft, those files are exposed to whoever carries the session.

This is not a failure of perimeter security in the sense that something is misconfigured. It is a structural limitation of what perimeter security is designed to do. It authenticates at the boundary. It does not authenticate at the file.

Stop Breaches Before the Alert Fires

Detection tools only tell you when a threshold has already been crossed. See how context-aware encryption blocks unauthorized file access in real time on every attempt.

Request a Platform Demo

What Detection Tools Can and Cannot Do When Credentials Are Stolen

Tools like CrowdStrike, SentinelOne, and Splunk are valuable parts of any security stack. The argument here is not that they are ineffective — it is that they are retrospective by design, and that for credential theft specifically, the early stages of an attack are often indistinguishable from legitimate use.

Detection works by identifying deviations from a baseline. An endpoint behaving normally, accessing files that a user in that role would reasonably access, during hours that are not dramatically outside their pattern, will not produce an alert. This is exactly the scenario in the opening example. The attacker accessed files the finance director's account had permission to access, during late-night hours that were not unprecedented for a senior employee, from an IP address associated with a common VPN exit point.

The 340-file access volume that ultimately triggered the alert did so because it crossed a threshold. But 340 files were already read before the alert fired. IBM's Cost of a Data Breach report puts the average breach detection time at more than 200 days. Even when detection is faster — hours rather than months — the damage window is defined by how many files an attacker can access before the anomaly pattern becomes statistically distinct from normal behavior.

The IBM report also puts the average breach cost at approximately $4.88 million. For incidents involving federal government systems and insider actors, the Ponemon Institute estimates the cost per incident reaches $22.2 million. These numbers reflect what happens when the defensive architecture relies primarily on detection. Detection tells you when the breach started. It does not limit what was accessed before the alert fired.

We covered why detection alone cannot stop insider threats in detail in a previous post. This post focuses on what the solution looks like at the file layer — the control that operates after login, independent of whether the identity is trustworthy.

How Context-Aware File Encryption Changes the Equation After Login

The structural problem with detection and perimeter controls is that both assume the identity presenting credentials is who they claim to be. File-layer encryption with context-aware access controls does not make that assumption. It evaluates whether the combination of identity, device, location, network context, and behavioral baseline collectively authorizes access to a specific file, and it does this check on every file open event, not once at login.

Theodosian applies per-file FIPS 140-3 validated AES-256 encryption with a unique encryption key per file. The zero-knowledge architecture means that even Theodosian cannot decrypt a customer's files — the keys are derived from a combination of factors that must all be present at the moment of access. Stealing a credential is necessary but not sufficient. The attacker also needs the authorized device, the expected geolocation, the correct network context, and a behavioral pattern consistent with the legitimate user's history.

In practice, this means that when the attacker in our scenario attempts to open the first budget file, the decryption attempt fails. The credential is valid. The session is authenticated. But the device is not the finance director's enrolled workstation, the geolocation is not consistent with their access history, and the network context does not match. The file does not open. The key is not released. The attacker sees an encrypted object they cannot read.

Context-aware access control at the file layer goes well beyond role-based permissions. Traditional RBAC grants access based on the role assigned to an identity. Dynamic access control incorporates the real-world context of each access attempt — when it happens, where it happens, what device is involved, and whether the pattern is consistent with the user's established behavior. This difference matters because an attacker with stolen credentials inherits the victim's role but cannot replicate their full access context.

The comparison between per-file encryption and disk-level encryption or DLP is relevant here: disk encryption protects data at rest on a device but does nothing once the OS has authenticated and mounted the drive. DLP scans for data in motion but cannot prevent access to a file that a valid identity is authorized to open. Per-file encryption is the only control that travels with the file and enforces access rules at the moment of decryption, regardless of where the file sits or who is presenting credentials.

What Is Drop the Gate, and How Does It Respond Before Your Team Is Paged?

Context-aware decryption controls block the obvious attack — an attacker operating from an unrecognized device in an unusual location. But what about a scenario where the attacker has managed to access the victim's enrolled device, or where the context checks are closer to the threshold than a clear violation? This is where Theodosian's Drop the Gate capability becomes relevant.

Drop the Gate monitors access behavior in real time across all file activity. When it detects a pattern consistent with a threat — rapid sequential file access, access at an unusual hour for that specific user, access to a file classification level the user rarely touches — it does not wait for a human analyst to review an alert. It autonomously freezes access to protected files and triggers step-up MFA for the active session. The response is automatic and immediate.

The significance of this is timing. In a traditional security operations workflow, an anomaly alert fires, gets queued, is reviewed by an analyst, is escalated if confirmed, and then action is taken. That chain takes time. Drop the Gate collapses that chain: the detection and the response are coupled in the same automated action. The attacker's session is frozen before the security team has been paged, not after they have been paged, assigned the ticket, confirmed the threat, and decided to act.

This is the difference between prospective and retrospective control. Detection is retrospective — it identifies what has already happened. File-layer encryption and autonomous response are prospective — they operate on the access attempt itself, before the data has been read.

How Does This Apply to Malicious Insiders — Not Just External Attackers?

The finance director scenario involves an external attacker using stolen credentials. The harder case is the malicious insider: an employee who has valid credentials, an enrolled device, works from an expected location, and has a behavioral baseline that looks like normal use. This person is not presenting anomalous signals at login. They are authenticated in every meaningful sense.

File-layer controls address the insider threat through a different mechanism. Access is governed not just by identity but by data classification and role. A finance analyst has access to budget files within their scope, but not to engineering specifications, export-controlled technical data, or HR records at a sensitivity level above their clearance. The access boundary is enforced at decryption, not at the folder permission level. An insider who navigates to a folder they are not authorized to open finds encrypted files they cannot decrypt.

When a malicious insider begins testing those boundaries — attempting to access files outside their normal scope, accessing high volumes of documents in a short window, or accessing files they have never opened before — Drop the Gate flags the behavioral deviation and intervenes autonomously. The $22.2 million average cost of a federal insider incident reflects scenarios where this kind of activity was not caught until significant data had been exfiltrated. File-layer behavioral controls reduce that window because they respond to access patterns, not to exfiltration events that occur downstream.

The contractor offboarding scenario is a related risk. When a contractor's access is terminated, every file they were authorized to open becomes inaccessible at decryption. There is no need to inventory which files they may have copied, because copies remain encrypted and unreadable outside the authorized context. The key is revoked. The data does not move with the person.

limiting blast radius of credential theft

What Does File-Layer Protection Actually Require to Deploy?

A common assumption about file-level encryption is that it requires significant data migration, re-architecting of storage, or extended integration timelines. The reality of deploying Theodosian is more straightforward than most security leaders expect.

Deployment does not require data migration. Existing files are encrypted in place. The platform runs on FedRAMP Moderate infrastructure, which matters for organizations operating in defense supply chain contexts or handling controlled unclassified information under CMMC. There is no requirement to move data to a new storage environment before protection takes effect.

The standard proof of concept runs for two weeks. In that window, the platform is configured, context-aware access policies are defined, and Drop the Gate thresholds are set against the organization's actual behavioral baselines. The output is not a report — it is production-ready protection on the files that matter most, with evidence of how the system would have responded to access events in the POC window.

For organizations facing CMMC Level 2 requirements, ITAR obligations, or export control compliance, the per-file encryption and access audit trail Theodosian generates addresses multiple control requirements simultaneously. Every access event, every failed decryption attempt, every Drop the Gate trigger is logged with the context that was evaluated — identity, device, location, network, timestamp. That log is the audit trail.

Take Control of Your File-Layer Security

Valid credentials shouldn't equal unrestricted data access. Protect your files at rest, in transit, and in use across all your platforms with continuous, zero-knowledge encryption.

Schedule a Theodosian Demo Today

FAQs: File-Layer Security & Credential Theft

What is insider threat protection, and how is it different from detection?

Insider threat detection uses behavioral analytics to identify when an employee's actions deviate from their established baseline and flags those deviations for analyst review. Insider threat protection — in the file-layer sense — enforces access restrictions at the point of decryption, independent of whether the identity has been authenticated. Detection identifies anomalies after access has occurred. File-layer protection prevents access to files the identity is not authorized to decrypt, before the file content is read. The two controls address different moments in the attack sequence and work best together.

Can credential theft protection work if the attacker has passed MFA?

Standard MFA authenticates identity at login time. Once MFA is satisfied, the session carries the trust level of the authenticated identity, and that trust is not re-evaluated on subsequent file access events. File-layer encryption with context-aware access controls re-evaluates authorization on every file open, checking device enrollment, geolocation, network context, and behavioral baseline in addition to identity. An attacker who has passed MFA using a relay or real-time phishing kit still lacks the authorized device, the expected location, and the established behavioral pattern. Those missing factors prevent decryption.

Does file-layer encryption slow down legitimate users?

The decryption evaluation happens at the OS level and is designed to be transparent to the user when the access context is normal. A legitimate user on their enrolled device, in their expected location, accessing files within their authorized scope will not experience a workflow interruption. The friction appears only when the access context deviates from the authorized baseline — which is precisely when friction is warranted.

How does this differ from DLP for protecting against credential theft?

DLP tools inspect data in motion and apply policies to transfers, uploads, and transmissions. They can block a file from being emailed to an unauthorized address, but they operate downstream of file access — they see the file after it has been read and after an action is attempted. DLP cannot prevent an authenticated user from reading a file; it can only attempt to control what they do with it afterward. File-layer encryption prevents the read event itself when the access context is not authorized.