This piece marks the third installment in our ongoing series analyzing compelled decryption laws. As digital evidence continues to play a central role in modern investigations, legal systems worldwide are actively addressing the friction between encrypted devices and law enforcement access. For this chapter, our geographic focus shifts to East Asia. The region provides a highly practical comparative landscape for observing how neighboring jurisdictions weigh the technical demands of modern forensics against individual procedural rights. To map these diverse approaches, the following sections review the current legal mechanisms in mainland China, Hong Kong, Taiwan, Japan, and South Korea.

Mainland China

Key Points:

• A legal system that prioritizes state security and investigative access over a broad individual right to refuse cooperation.
• The clearest decryption duties fall on network operators, telecommunications companies, and internet service providers.
• Cybersecurity and counter-terrorism laws explicitly require these entities to provide technical support, including decryption assistance in some contexts.
• The system strongly favors state access, but current statutes do not clearly create a standalone criminal offense for an ordinary suspect who refuses to unlock a personal device.

In the People’s Republic of China, digital investigations operate within a framework that prioritizes state security and investigative access over an individual right to refuse cooperation. Rather than building the justice system around an expansive right to silence, mainland law gives security authorities broad access powers and imposes specific duties of technical assistance on regulated entities, particularly in matters of national security, public safety, and counter-terrorism.

However, the legal mechanics of compelled decryption are more specific than often assumed. While criminal procedure laws impose a general civic duty to report crimes, they do not contain a blanket decryption mandate for ordinary citizens. Instead, the clearest and most forceful digital-access rules target corporate entities.

Under the country’s cybersecurity and counter-terrorism statutes, the burden of access falls heavily on network operators, telecommunications companies, and internet service providers. These laws legally bind operators to provide technical support to public and state security organs. In terrorism investigations, the mandate goes even further, expressly requiring service providers to supply technical interfaces and decryption assistance, backed by severe corporate penalties for non-compliance.

This creates a distinct legal reality: mainland Chinese law unequivocally compels decryption assistance from regulated technology providers. What it does not clearly do—at least on the face of current statutes—is create a neatly defined, standalone criminal offense that automatically penalizes an ordinary individual simply for refusing to hand over a personal passcode. The system undeniably favors state access, but it anchors its strictest decryption duties and enforceable penalties on the entities operating the networks rather than the individual suspect.

This framework, however, remains fluid. On January 31, 2026, the Ministry of Public Security published a Draft Law on Cybercrime Prevention and Control. While currently only a draft rather than enacted law, it signals an ongoing effort to consolidate and potentially expand the state’s oversight of digital spaces.

Hong Kong

Key Points:

• The implementation of the National Security Law significantly altered the region’s legal landscape.
• Amendments enacted in March 2026 explicitly empower law enforcement to compel individuals to provide device passwords, specifically within the context of national security investigations.
• Authorities are required to obtain legal authorization before compelling decryption, and refusing a lawful request is a criminal offense punishable by fines and up to a year in prison.

Once a territory under the British Crown, Hong Kong was transferred back to Chinese sovereignty under the premise of “one country, two systems.” This diplomatic arrangement was designed to maintain the region’s status quo, preserving its independent judiciary, capitalist economy, and common law legal traditions distinct from the mainland. However, observing the current legal environment reveals a gradual shift in that structural separation, particularly in how digital rights and investigative powers are managed.

The implementation of the National Security Law (NSL) served as the primary catalyst for altering the region’s legal landscape, bridging the gap between Hong Kong’s common law history and a more centralized, security-oriented approach. Under amendments to the NSL implementation rules enacted in March 2026, law enforcement agencies are now empowered to compel individuals to hand over device passwords and provide decryption assistance. The scope of these provisions is formally restricted to cases involving matters of national security. Furthermore, procedural scrutiny is required; officials have clarified that police cannot randomly demand passcodes from the public. Law enforcement must first secure the appropriate legal authorization or a warrant to search the device before a password demand can be made.

Once that legal authorization is obtained, however, the burden is placed directly on the device owner or user. In these specific national security contexts, refusing to cooperate is not shielded by the traditional right to remain silent. The updated rules classify non-compliance as a criminal offense carrying substantial penalties that include fines of up to HK$100,000 and up to a year in prison.

Taiwan

Key Points:

• A self-governing democracy that maintains strict constitutional barriers against state coercion in digital spaces.
• Article 95 of the Taiwanese Code of Criminal Procedure explicitly protects the right against self-incrimination.
• The prevailing legal consensus views compelled password disclosure as a violation of procedural protections.
• Authorities are unable to legally criminalize a suspect’s refusal to supply an encryption key, relying instead on independent forensic capabilities.

Taiwan operates as a self-governing democracy, maintaining its distinct political and legal systems while navigating the persistent geopolitical threat of annexation. This ongoing reality has fostered a legal environment that is highly sensitive to state overreach and firmly anchored in democratic due process.

Reflecting these principles, the jurisdiction maintains strict barriers against state coercion in digital investigations. Article 95 of the Taiwanese Code of Criminal Procedure explicitly protects a suspect’s right against self-incrimination, a safeguard that the legal community applies directly to digital devices. The prevailing legal consensus across the country is that compelling an individual to disclose a password or encryption key constitutes a clear violation of these core procedural protections. Consequently, authorities cannot legally criminalize a suspect’s refusal to unlock a device. To access encrypted evidence, Taiwanese law enforcement must rely entirely on independent forensic capabilities and technical analysis rather than legal compulsion, preserving a definitive boundary between state investigative powers and the right to remain silent.

The Chinese Ecosystem: A Comparative Summary

Observing this specific geographic and political cluster provides a clear illustration of how different governance models directly shape the rules of digital evidence.

Mainland China anchors one end of the spectrum, operating under a framework where individual digital autonomy is structurally subordinated to the mandates of the security apparatus. The legal baseline strongly favors state access, placing the clearest and strictest decryption duties on network operators, telecommunications companies, and internet service providers.

Hong Kong currently occupies a practical middle ground. The territory applies these state-first compliance rules strictly to matters involving national security, while generally preserving its traditional protections against self-incrimination for standard criminal investigations.

Across the strait, Taiwan offers a direct contrast by actively defending the right against self-incrimination across the board. The jurisdiction maintains a recognized boundary between the state’s investigative reach and individual procedural rights, leaving the burden of decryption entirely on the authorities.

Japan

Key Points:

• A system navigating the friction between constitutional protections against self-incrimination and statutory requests for investigative cooperation.
• Article 38 of the Constitution guarantees the right to silence and prohibits coerced confessions.
• Article 111-2 of the Code of Criminal Procedure allows authorities executing a warrant to ask suspects to operate a device or provide “some other form of cooperation,” a phrase understood to include decryption.
• The core ambiguity lies in this permissive wording: the statute authorizes a request for cooperation, but does not resolve how far investigators can push that request before violating Article 38.

Japan’s justice system faces a unique friction point when it comes to digital evidence. At the constitutional level, Article 38 guarantees the right to remain silent and prohibits convictions based on coerced confessions. However, this foundational shield intersects with the country’s Code of Criminal Procedure. Under Article 111-2, when officers execute a search or seizure warrant involving electronic-record media, they may ask the person subject to the measure to operate the computer or provide “some other form of cooperation” – a clause understood to include decryption.

This is where the ambiguity arises. Article 111-2 gives investigators a statutory basis to request assistance, but its wording is strictly permissive. Officers “may ask” for cooperation, but the law does not expressly criminalize refusal or settle how far that request can be pressed against Article 38’s protection against self-incrimination. Because pushing a suspect to unlock a device raises immediate constitutional concerns, Japanese law enforcement tends to tread carefully. Rather than relying strictly on direct legal pressure, investigators lean on third-party forensic tools to unlock devices independently, or use standard interrogation to persuade suspects to grant access voluntarily. This approach reflects a system actively trying to navigate the digital barrier while reducing the risk of a constitutional clash.

South Korea

Key Points:

• A highly digitized society actively debating how digital evidence intersects with the right to remain silent.
• Constitutional protections against self-incrimination frequently stall investigations when suspects refuse to unlock devices.
• A prominent 2020 legislative push attempted to criminalize the refusal to provide a password, but the proposal was ultimately scrapped.
• The push faced severe pushback from civil rights advocates, maintaining that forced decryption violates fundamental constitutional boundaries.

South Korea presents the case of a highly digitized society still debating how to handle digital evidence. Rooted in constitutional protections against self-incrimination, the legal system frequently runs into a familiar barrier when suspects withhold their passcodes. This creates a distinct bottleneck for law enforcement, as prosecutors and police often find their inquiries stalled when key figures simply refuse to unlock their smartphones or computers.

To address this investigative standstill, there was a prominent legislative push in 2020 to introduce a compelled decryption law. The proposal sought to penalize non-compliance, effectively treating the refusal to provide a phone password as an independent criminal offense. However, the effort was later scrapped amid intense criticism and human rights concerns. Civil rights groups and legal professionals argued that forcing an individual to disclose a password crosses a fundamental boundary, directly violating the constitutional protection against compelled self-incrimination.

This leaves South Korea in an unsettled position. While authorities actively seek a statutory mechanism to ensure investigative access, the legal basis for compelling an ordinary suspect to unlock a personal device remains contested in light of existing constitutional safeguards.

Conclusion

Ultimately, the East Asian landscape provides a clear map of a growing bifurcation in global law regarding compelled decryption. Looking at the region’s varied approaches to digital forensics and individual rights, two distinct paths emerge. Jurisdictions structured around centralized state control generally give investigative authorities broader access powers and impose stronger duties of technical assistance, especially on regulated service providers. In contrast, jurisdictions that emphasize democratic due process continue to work through the everyday friction between modern investigative demands and the historical preservation of the right against self-incrimination.

The first part of this series examined jurisdictions that have adopted a coercive approach to cryptographic barriers. Nations such as the United Kingdom, Australia, and France navigate the practical hurdles of end-to-end encryption through statutory workarounds. Rather than attempting to break the encryption itself, these legal systems apply pressure directly to the device owner – even if the owner is the suspect. By treating the refusal to provide decryption keys or passwords as a standalone criminal offense, they effectively bypass the technical roadblock. Under this model, non-compliance triggers its own set of penalties, entirely separate from the underlying investigation.

This second part turns to a different legal paradigm, examining jurisdictions that prioritize established civil liberties over state access. The focus here rests on legal frameworks maintaining that foundational constitutional protections – most notably the privilege against self-incrimination – cannot be set aside simply to accommodate investigative convenience. For these nations, forcing a suspect to produce a password or PIN crosses a critical line, shifting from the lawful seizure of physical evidence to the unlawful compulsion of testimony. The following chapters explore how these countries structure their laws to preserve traditional rights, even as the realities of modern digital forensics present unprecedented challenges for law enforcement.

The Protectors of Digital Rights

In contrast to jurisdictions that penalize a suspect’s refusal to decrypt personal devices, a distinct cohort of nations – prominently including Canada, Germany, Belgium, and the Netherlands – anchors its approach in established constitutional and procedural safeguards. Rather than treating investigative access as an absolute imperative, these legal systems maintain that the fundamental privilege against self-incrimination must endure in the digital arena. Within this framework, courts and legislators generally separate the lawful oversight of third-party telecommunications providers from the direct coercion of the individual suspect.

Canada

Canada stands against the coercive decryption model. The Canadian judicial system evaluates these modern police practices strictly through the lens of the Canadian Charter of Rights and Freedoms, specifically Section 7, which guarantees the right to life, liberty, and security of the person. This section has been heavily interpreted to encompass the right to silence and robust protection against self-incrimination. Canadian courts have consistently rebuked attempts by the Crown to force suspects to divulge passwords.

In the pivotal case of R. v. Shergill (2019 ONCJ 54), the Ontario Court of Justice faced a novel application by the Crown seeking an “assistance order” under section 487.02 of the Criminal Code to compel an accused to unlock a seized cellphone. The police openly admitted they lacked the technology to bypass the phone’s security without destroying the data. Justice Philip Downes explicitly recognized the immense challenges law enforcement faces with modern encryption but ultimately balanced the public interest in prosecuting crimes against the accused’s liberty interests under the Charter. The court flatly refused to order the accused to unlock the smartphone, reinforcing that the right to silence unequivocally extends into the digital realm.

This protective stance was further reinforced by the Ontario Court of Appeal in R. v. O’Brien (2023 ONCA 197). In O’Brien, the court approached police demands for device passwords through the lens of the Charter, emphasizing the inherently coercive circumstances of the search, the lack of truly informed consent, and the failure to provide a meaningful opportunity to exercise the right to counsel before access was obtained. The decision underscores that consent to search a digital device cannot be manufactured through state pressure, confusion, or ignorance of one’s rights.

Germany

Germany operates as a prominent stronghold for digital privacy within the European Union, anchoring its approach to compelled decryption in the foundational legal principle of nemo tenetur se ipsum accusare – the right not to incriminate oneself. Under the German Code of Criminal Procedure (Strafprozessordnung, or StPO), the right to silence is protected in the digital realm. While investigators are fully authorized to seize locked devices and attempt to extract data using their own forensic tools, the law strictly prohibits forcing suspects to surrender their personal passwords, PINs, or cryptographic keys. Compelling an individual to actively unlock their own device is treated as an unacceptable breach of this core procedural safeguard, ensuring that suspects cannot be coerced into handing over the exact tools needed for their own prosecution.

This procedural shield is heavily reinforced by Germany’s highest court. In a landmark 2008 ruling, the Federal Constitutional Court (Bundesverfassungsgericht) established a specialized constitutional protection: the fundamental right to the confidentiality and integrity of information technology systems (often referred to as the “IT fundamental right”). Derived from the broader right of personality outlined in the German Basic Law, this ruling set a high judicial bar for state interference with personal computing devices. The court effectively recognized that modern digital devices require explicit and stringent protections against unwarranted state access.

Consequently, the German legal framework places the technical burden of decryption entirely on the state. If law enforcement encounters a heavily encrypted smartphone, investigators must rely on their own technical resources to bypass the security, and cannot jail the device owner for refusing to provide the password.

Netherlands

Dutch legislation embeds the privilege against self-incrimination directly into its statutory text regarding digital forensics. Article 125k of the Dutch Code of Criminal Procedure empowers investigators to issue a decryption order to individuals who possess specific technical knowledge of the encrypted system in question. However, the statute explicitly dictates that this legal order absolutely cannot be issued to the suspect. Tellingly, this core protection has been actively preserved even as the country undergoes a sweeping, multi-year Modernization of Criminal Procedure.

The Biometric Compromise

The global legal landscape surrounding compelled decryption is vast, and this analysis does not attempt to review every jurisdiction. Many nations would comfortably align with either the coercive or protective camps. For the purposes of this scope, developing nations, autocracies such as China and Russia, and much of the Asian region – including Japan and South Korea – are still waiting to be explored. Comprehensively cataloging every national approach in a single text, or even two, is impossible and falls outside the primary goal of examining this core legal divide.

Between the extremes of criminalizing digital silence and absolutely protecting it, a widespread compromise has emerged across numerous jurisdictions: compelled biometric unlock. As device manufacturers transitioned away from typed passwords and seamlessly integrated fingerprint and facial recognition technologies, they unintentionally provided law enforcement with a legal loophole. This rapid technological shift introduced a profound vulnerability into the jurisprudence surrounding self-incrimination.

Constitutional protections against self-incrimination are fundamentally designed to shield the “contents of the mind,” preventing the state from forcing an individual to share a memorized code or articulate a thought. Conversely, the law has long maintained that physical traits do not constitute compelled testimony. This strict legal dichotomy is deeply rooted in nineteenth-century forensic science. Following the development of Alphonse Bertillon’s anthropometry (Bertillonage) and the global rise of dactyloscopy, courts universally accepted that measuring a suspect’s physical body or taking their fingerprint did not violate the right to silence.

Modern prosecutors have utilized this historical distinction. Because a fingerprint or a face is classified as a physical attribute rather than a memorized secret, courts routinely rule that forcing a suspect to unlock a device via biometrics does not trigger self-incrimination protections. Armed with this reasoning, law enforcement agents regularly secure search warrants authorizing them to physically press a suspect’s thumb onto a scanner or forcibly hold a smartphone to a suspect’s face. Under this framework, the human body is legally reduced to a physical key.

This creates a procedural paradox. A suspect who relies on a traditional PIN can legally invoke their right to silence and refuse to surrender the code, while a suspect utilizing a biometric shortcut for the exact same cryptographic code can be physically restrained and forced to unlock the device without any recognized constitutional violation occurring. The legal outcome relies entirely on the technical distinction between what the suspect knows versus what the suspect is.

While this biometric workaround remains widely exploited by authorities, there are signs of judicial resistance. In January 2025, the D.C. Circuit Court of Appeals issued a potentially landmark ruling in United States v. Brown, concluding that compelling a defendant to unlock a cellphone with a fingerprint actually violated his Fifth Amendment right against self-incrimination. The court reasoned that the compelled biometric unlock was inherently “testimonial” because it explicitly communicated the suspect’s control and ownership over the device and its hidden contents.

Conclusion

The global legal landscape is currently defined by a collision between modern cryptography and the coercive power of the state. In an effort to bypass encryption, several jurisdictions have granted police the leverage to force suspects to unlock their devices under the threat of severe penalties. However, this approach effectively hollows out the ancient legal principle of nemo tenetur se ipsum accusare – the right against self-incrimination.

This increasing reliance on statutory coercion, coupled with the exploitation of outdated biometric loopholes, signals a significant shift in the balance of legal power. If these practices continue unabated, the fundamental protection against forced self-incrimination risks surviving only as a theoretical construct on paper, largely disconnected from the digital reality where everyday human life now occurs.

References

Canada

• Forced Unlocking Amounts to Self-Incrimination – Canadian Technology Law Association
• Ontario court refuses to order accused to unlock his smartphone – Privacy Lawyer
• The Right to Silence Carries the Right to Keep Passwords Secret – McCarthy Tétrault LLP

Netherlands

• Cybersecurity Laws and Regulations Report 2026 Netherlands – ICLG.com

Germany

• Bundesverfassungsgericht – Decisions search – Judgment of 27 February 2008
• Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme – Wikipedia

Biometric Unlock (Various Jurisdictions)

• The Fifth Amendment, Decryption and Biometric Passcodes – Lawfare
• Biometrics vs. the Fifth Amendment – New America
• Do Compelled Biometrics Violate the Fifth Amendment? A Deepening Split Among Lower Courts – The Federalist Society
• Does the Fifth Amendment Protect Biometrics? – Purdue Global Law School
• When Your Fingers Do the Talking: D.C. Circuit Rules That Compelled Opening of Cellphone With Fingerprint Violates the Fifth Amendment – Arnold & Porter

On March 23, 2026, the Hong Kong government amended the rules of its National Security Law, making it a criminal offense to refuse police passwords or decryption assistance for personal devices. When I read the security alert, my initial plan was simply to compile a list of jurisdictions with similar laws. That catalog quickly outgrew its premise. Tracking these statutes revealed a fractured global approach to digital privacy and state power, resulting in a comparative study too broad for a single article. I decided to split the research into two parts. This first installment examines the countries that criminalize digital silence.

The catalyst for these laws is strictly technological. Modern electronic devices hold an unprecedented concentration of our private lives. At the same time, the widespread adoption of strong encryption has built mathematical walls that investigative agencies cannot breach. Faced with this barrier, the state’s focus has shifted. Unable to break the device, governments increasingly use the threat of separate jail time to compel the user to open it.

This dynamic forces a re-examination of the right against self-incrimination. The core debate asks whether forcing a suspect to hand over a password is akin to surrendering a physical key, like a safe combination, or if it constitutes forcing them to testify against themselves. This article maps out the jurisdictions that bypass that debate entirely, choosing instead to make the refusal to decrypt an independent crime.

The Offenders

As I mapped out how different legal systems handle the encryption roadblock, a distinct, highly pragmatic pattern emerged. The philosophical debate over whether a password is a physical key or a piece of testimony is legally rich, but it is also incredibly slow. For an investigator staring at a locked device that might hold the centerpiece of a case, abstract constitutional theory offers little immediate use.

A growing number of jurisdictions have decided they simply do not have the patience for that debate. Rather than untangling the historical nuances of self-incrimination, they bypassed the problem entirely by creating a brand new crime.

In these countries, digital silence is a standalone offense. The logic is a fascinating piece of legislative circumvention: the state is not punishing you for whatever illicit material might be hidden on your hard drive because they cannot see it. Instead, you are prosecuted strictly for the act of keeping the door locked. By severing the refusal to provide a password from the underlying criminal investigation, these governments have weaponized the penal code against the locked screen itself.

It is a blunt, highly effective workaround to the mathematics of encryption. Here is how that hardline approach plays out on the ground.

The United Kingdom

When tracing the origins of the coercive model, the path leads directly to the United Kingdom. The British approach serves as a primary blueprint for how a state can pivot its penal code against a locked screen.

The mechanism driving this is the Regulation of Investigatory Powers Act 2000, commonly known as RIPA. Under Section 49 of the act, police and other authorities can serve a formal notice demanding a suspect hand over their password, PIN, or decryption key. To issue this demand, authorities need a reasonable belief that the person knows the code and that access is necessary to prevent crime, protect national security, or safeguard the country’s economic well-being; the notice also has to be necessary, proportionate, and used where it is not reasonably practicable to obtain the intelligible information another way.

The real teeth of the legislation reside in Section 53. Failing to comply with a Section 49 notice without a lawful excuse is classified as a standalone criminal offense. The penalties are explicitly designed to act as a coercive lever: a standard refusal carries a maximum two-year prison sentence, but if the underlying investigation involves national security or indecent images of children, that penalty jumps to five years.

Watching this dynamic operate in practice, the legal paradox it creates inside an interrogation room is striking. Suspects are forced into a high-stakes calculation, having to immediately weigh whether the data on their device is so incriminating that taking a guaranteed prison sentence for silence is a better bet than facing the primary charges.

It is easy to mischaracterize how this looks on the ground. When I first started assembling notes for this section, I looked at the case of Stephen Nicholson, who refused to hand over his Facebook password during the 2018 Lucy McHugh murder investigation. It is tempting to frame his resulting prison sentence as an example of a man locked up “strictly for withholding a password” – but looking at the actual timeline breaks that narrative.

Nicholson was the prime suspect in a murder case. When he refused to yield his password, the state didn’t wait for the homicide investigation to conclude. They hit him with a RIPA charge immediately, resulting in a 14-month prison sentence in August 2018. This allowed authorities to effectively incarcerate an uncooperative murder suspect while they built the primary case against him. By July 2019, Nicholson was convicted of the rape and murder. In this context, RIPA functioned less as a standalone punishment and more as an immediate tactical holding maneuver for a much darker crime.

To see how the law operates completely independent of underlying guilt, a clearer example is the case of Tajan Spalding. Spalding was handed an eight-month prison sentence for refusing to provide the passcodes to his iPhone and iPad during a drug investigation.

France: an Act of Staying Silent as an Active Obstruction of Justice

France, a country whose national motto was Liberté, égalité, fraternité, has taken a surprisingly hardline stance on digital privacy under Article 434-15-2 of its Penal Code. This law makes it a severe criminal offense to refuse to hand over a decryption key or password to law enforcement during an investigation. For a while, there was legal back-and-forth about whether a standard smartphone PIN actually counted as a decryption key or just a simple lock. However, in late 2022, France’s highest court, the Court of Cassation, definitively settled the debate: a phone PIN is legally recognized as a decryption tool if the phone is encrypted. Refusing to provide it to the police can land you with a prison sentence of up to three years and a staggering €270,000 fine.

The key nuance here is that this obligation falls on absolutely anyone who knows the code, up to and including the suspect themselves. This raises obvious and tricky questions about the right against self-incrimination, a cornerstone of many legal systems. The French courts, however, have effectively bypassed this protection by framing the refusal not as an act of staying silent, but as an active obstruction of justice. They argue the code isn’t inherently incriminating evidence; it’s just the key to access a space where evidence might be.

For the average private citizen, this means the old idea that “my phone is my private digital vault” doesn’t hold much water if you’re ever taken into custody. You can be hit with heavy criminal charges purely for keeping your passcode to yourself, completely separate from whatever crime the police were originally investigating.

To be fair, the Court of Cassation did introduce a technical caveat in its November 2022 ruling, clarifying that a phone PIN isn’t automatically considered a “decryption key” by default. The judges specified that for the offense to trigger, the state must prove the specific device is actively equipped with encryption software and that the PIN actually unscrambles the data, rather than just acting as a simple home screen lock. While this sounds like a meaningful privacy safeguard on paper, it is a slightly cynical moot point in the real world. Virtually all modern smartphones come with full-device encryption enabled out of the box. Ironically, if a suspect happened to possess an older, unencrypted phone where the passcode merely locked the screen, law enforcement wouldn’t need to compel them to reveal the code anyway – they could easily bypass the lock and pull the data using standard forensic extraction tools. So, while the court drew a careful legal distinction, the everyday reality of consumer tech ensures the threat of prosecution remains practically universal.

Belgium

The Belgian legislative model, primarily governed by Article 88quater of the Code of Criminal Procedure, offers a deeply nuanced approach that actively splits the difference between physical action and abstract knowledge. The law draws a sharp distinction regarding what can actually be compelled. Under §2 of the article, an investigating judge can order a suitable person to operate a computer system or carry out technical actions; crucially, that order cannot be directed at the suspect, thereby protecting the accused from being forced to actively participate in the search of their own device. However, §1 creates a significant caveat by allowing authorities to require access-enabling information from a person believed to possess the necessary knowledge, and Belgian case law has confirmed that this can include the suspect.

Following rulings by the Belgian Court of Cassation and the Constitutional Court in 2020, the practical position of Belgian law is that, while the state cannot force a suspect to personally unlock or operate a seized phone under §2, it can punish refusal to disclose access codes under §1 and §3, on the reasoning that such codes constitute pre-existing information rather than compelled participation in the collection of evidence.

In essence, Belgium draws a procedural distinction between forcing the suspect to operate the device and forcing the suspect to reveal the secret needed to unlock it. But for the purposes of nemo tenetur se ipsum accusare, that distinction does not alter the underlying reality: the state may still compel disclosure of “something that the suspect knows” under threat of punishment. Belgium therefore belongs in the coercive camp.

Australia

Looking further afield, the Australian framework caught my attention for its sheer punitive weight. The foundation of this approach was laid when the Cybercrime Act 2001 inserted Section 3LA into the federal Crimes Act. While much of the modern public debate around encryption focuses on forcing major tech companies or telecommunication providers to build systemic backdoors, Section 3LA zeroes in squarely on the individual. It is a legal lever designed exclusively to compel physical persons – suspects and witnesses alike – to unlock their personal devices. This leaves corporate responsibility out of the equation as Australia aggressively targets tech companies through parallel legislation like the 2018 TOLA Act.

Under this provision, if law enforcement believes a device holds evidence of a crime, they can obtain a magistrate’s order forcing the specified person with knowledge to provide the necessary passwords, PINs, or biometric access. The mechanism is simple: you are handed a warrant, and your failure to immediately decrypt the phone or laptop becomes a standalone federal offense. There is no drawn-out constitutional debate inside the interrogation room about the historical right to silence. The state simply demands the keys, and the individual must make an immediate choice.

What makes the Australian model staggering is the consequence of saying no. In investigations involving serious federal offenses, refusing a Section 3LA order carries a maximum penalty of ten years in prison. This is not a subtle legal nudge; it operates as an overwhelming coercive force. By threatening a decade behind bars strictly for keeping a screen locked, the law effectively neutralizes any practical reliance on the privilege against self-incrimination. It creates an environment where the individual is strong-armed into doing the investigative heavy lifting for the state, rendering their digital silence a highly penalized luxury.

New Zealand

As a direct neighbor to this Australian framework, New Zealand offers a compelling bonus case study in how state coercion is applied directly to the individual. Under Section 130 of the Search and Surveillance Act 2012, New Zealand law enforcement officers executing a search warrant possess the explicit authority to compel a physical person to provide the PIN, password, or encryption key to a lawfully seized device. Refusal to comply is not met with a procedural negotiation; it is prosecuted as a standalone offense punishable by up to 3 months’ imprisonment. Like the Australian model, this legislation zeroes in entirely on the personal responsibility of the suspect or witness holding the device, completely bypassing any reliance on the cooperation of external tech corporations.

It is important to note that this domestic investigative power operates parallel to an entirely separate border regime. When I initially looked into New Zealand’s approach, I had to draw a line between standard police powers and customs enforcement. Under the Customs and Excise Act 2018, border agents can demand travelers unlock their devices or hand over passwords under the much lower threshold of having “reasonable cause to suspect” wrongdoing. Refusal at the border triggers a distinct $5,000 NZD fine and potential prosecution. While border searches rely on a different legal foundation – rooted in a sovereign state’s inherent right to control its ports of entry rather than domestic criminal warrants – the underlying legislative mechanics remain similar.

Expanding the Map

Moving further East, the legal landscape surrounding compelled decryption fractures significantly, ranging from rigid statutory demands to complex constitutional debates.

In Singapore, authorities rely heavily on Section 39 of the Criminal Procedure Code (CPC). Following a suite of criminal justice reforms in 2018, Singaporean investigators were granted explicit, broad powers to order any individual to provide their login credentials or assist in decrypting a device. Crucially, this applies to anyone the police reasonably believe has knowledge of the password – whether they are the primary suspect, a family member, or a bystander. Refusing to hand over a passcode or help bypass security measures during a criminal investigation is treated as a direct obstruction of justice. The practical penalty reflected in a Singapore Police press release is up to S$5,000, 6 months, or both.

In Hong Kong, the legal boundary for forced decryption is explicitly tied to “National Security,” though the practical application of that term is notoriously broad. Under the March 2026 amendments to the Implementation Rules of the National Security Law (NSL), police officers can demand device passwords, decryption keys, or technical assistance. On March 27, the Hong Kong government publicly said police may require a password only after legal authorization to search the device has been obtained, and said there is no power to randomly demand passwords from ordinary people on the street. While this rule is technically confined to national security investigations, it applies to everyone physically present in the jurisdiction, both residents and visitors. Refusing to unlock a phone or laptop is a standalone criminal offense punishable by up to a year in prison and a hefty fine.

Contested Jurisdictions

While some nations have deployed blunt statutes to mandate decryption, other major democracies find themselves caught in a constitutional tug-of-war. In contested jurisdictions like the United States and India, law enforcement’s push for digital access constantly collides with deeply entrenched protections against self-incrimination. Rather than relying on a single, clear-cut law, these countries navigate an evolving patchwork of local court rulings, procedural workarounds, and ongoing legal debates. For the average person, this turns digital privacy into a highly unpredictable gray area, where the right to keep a passcode secret often depends less on unified legislation and more on how a specific judge decides to apply older legal principles to the smartphone era.

United States

Unlike the statutory coercion found in the UK and Australia where refusing to decrypt a device is a standalone criminal offense, the United States relies on procedural workarounds to force compliance. The primary hurdle for US law enforcement is the Fifth Amendment’s protection against self-incrimination, which generally covers the “testimonial” act of retrieving a password from your memory. To bypass this, prosecutors frequently invoke the “Foregone Conclusion” doctrine. If the government can prove they already know a suspect owns the device, knows the passcode, and can generally identify the files inside, courts in some jurisdictions have held that unlocking the device adds nothing to the government’s knowledge. This effectively strips away the Fifth Amendment shield. If a private citizen still refuses to comply with a judge’s decryption order, they aren’t charged with a new data-related crime; instead, they are held in civil contempt of court until they yield.

This procedural tactic has created a significant legal loophole, illustrated by the harrowing case of Francis Rawls. Suspected of possessing illicit digital material, Rawls was ordered to decrypt his hard drives. When he claimed he could not remember the passwords, the judge held him in civil contempt. The federal Recalcitrant Witness Statute is explicitly designed to cap this kind of coercive confinement at 18 months. However, prosecutors successfully argued for years that Rawls was a suspect rather than a mere witness, keeping the statutory limit at bay. As a result, Rawls was held in a federal detention center for over four years without ever facing a trial, a jury, or formal criminal charges. He was ultimately released in 2020 only after the Third Circuit Court of Appeals ruled the 18-month cap applied to him, highlighting how civil contempt can morph into an indefinite, uncharged prison sentence.

Rawls’s ordeal contrasts sharply with how similar cases are handled elsewhere in the country, showcasing the precarious geographic lottery of US digital rights. In the 2012 case In re Grand Jury Subpoena, the 11th Circuit Court of Appeals took a much stricter stance on the Foregone Conclusion doctrine. They ruled that because the government couldn’t identify with “reasonable particularity” what specific files were hidden on the encrypted drives, forcing the suspect to decrypt them fundamentally violated the Fifth Amendment. Because the US Supreme Court has yet to issue a definitive, nationwide ruling on compelled decryption, a citizen’s fundamental right to digital privacy – and their risk of being jailed for contempt – currently depends entirely on which federal circuit they happen to reside in.

India

In India, the legal landscape is currently caught in a tense tug-of-war between statutory power and constitutional rights that can be best described as “unsettled”. On one side is Section 69 of the Information Technology Act, 2000, which broadly compels individuals to provide technical assistance to decrypt data or face up to seven years in prison. On the other side is the Indian Constitution – specifically Article 20(3), which protects against self-incrimination, alongside the landmark Puttaswamy judgment that enshrined privacy as a fundamental right. This clash has sparked ongoing legal debates over whether forcing a suspect to hand over a memorized passcode constitutes an unconstitutional extraction of protected knowledge from their mind. Karnataka and Kerala High Courts have taken views allowing compelled disclosure, while the Delhi High Court said an accused could not be coerced to reveal passwords during an ongoing trial. Reporting from March 2026 also indicates the Kerala High Court has stayed a compelled-passcode order pending review.

Conclusion

Ultimately, the global patchwork of compelled decryption laws points to an ongoing shift in how justice systems navigate the digital age. Whether relying on explicit statutory offenses or procedural workarounds like civil contempt, authorities are steadily bypassing the nemo tenetur principle – the long-established safeguard against self-incrimination. From an analytical standpoint, this trend isn’t a simple matter of right versus wrong. Law enforcement naturally seeks the most efficient path to secure evidence, and encrypted devices present a genuine hurdle. However, redefining a memorized passcode as a mere physical key rather than protected personal knowledge structurally alters the legal landscape.

The core issue with eroding this principle is the resulting imbalance of power. The state already holds a natural monopoly on legal force and authority. Constitutional rights and historical legal doctrines exist specifically to counterbalance that weight, ensuring private citizens have a baseline defense against the machinery of prosecution. When courts and legislatures steadily chip away at the right to remain digitally silent, they tilt that scale heavily in the state’s favor. It establishes a dynamic where traditional boundaries on government power are quietly downgraded for the sake of technological convenience, significantly reshaping the equilibrium between the individual and the state.

Sources

• Section 49 RIPA Notices: Duties, Defences and Risks – PastPaperHero
• Prosecuted for your password – Saunders Law
• 3LA orders Crimes Act 1914 – NGM Lawyers
• Australia’s first-in-the-world ‘decryption’ laws will impact tech providers globally | IAPP
• Article 434-15-2 of the Penal Code: Refusal to unlock one’s phone, a new criminal offense – PCS Avocat
• French Court rules that refusing to disclose a mobile passcode to law enforcement is a criminal offence – Fair Trials
• New Hong Kong rules force people to give up passwords in security cases – CNA
• Hong Kong police can now demand phone and computer passwords under new national security rule – The Independent
• Criminal Procedure Code 2010 – Singapore Statutes Online
• Information Technology Act, 2000 – Wikipedia
• Whether an accused can be directed to disclose his phone password by the investigators? – Bharat Chugh
• United States v. Rawls – Wikipedia
• Suspect who refused to decrypt hard drives released after four years | SOPHOS
• In Re: Grand Jury Subpoena Duces Tecum Dated March 25, 2011, USA v. John Doe, No. 11-12268 (11th Cir. 2012) – Justia Law
• New Zealand Fines Travelers Who Won’t Unlock Secure Devices – MBT Mag

In July 2025, a tactical team of United States Marshals descended on the Tennessee home of Angela Lipps, arresting the fifty-year-old grandmother at gunpoint while she watched her young grandchildren. Her apprehension was not the culmination of traditional detective work, but the result of authorities placing undue confidence in an AI-based facial recognition system. An algorithm had linked a photograph of her face to a counterfeit military identification card used in a sophisticated bank fraud operation over 1,200 miles away in Fargo, North Dakota.

At its core, facial recognition software produces mathematical probabilities, not definitive facts. The technology is designed to offer an investigative lead, closer to an unverified tip phoned in by an anonymous informant than to actual evidence. Yet, in the Lipps investigation, that critical distinction was ignored. Investigators treated the algorithm’s probabilistic suggestion as actionable evidence, opting to secure a felony arrest warrant rather than conduct basic due diligence. Lipps would spend roughly six months incarcerated as a fugitive from justice before the state’s case ultimately fell apart. The reality of this breakdown leaves us with a fundamental, unsettling question: how could such a severe, life-altering error have been avoided by something as ordinary as checking a suspect’s alibi?

The Cost of Error

When an automated error crosses from a database into the physical world, the resulting damage is no longer just statistical. For Angela Lipps, the failure to verify an automated lead triggered a cascade of real-world consequences. The incident began with the immediate shock of being taken into custody at gunpoint in the presence of her grandchildren, but the collateral damage extended far beyond the initial arrest. Over the course of nearly half a year spent in jail, the infrastructure of her daily life was effectively dismantled. While she was incarcerated and navigating emerging health issues behind bars, she lost her rental home, her health insurance, and her pet. The public nature of the felony fraud allegations also damaged her reputation within her community. Even after the charges were dropped, she was released in North Dakota on Christmas Eve with no coat and no way home.

The official response only deepened the sense of institutional failure. Outgoing Fargo Police Chief David Zibolski refused to issue a formal, direct apology to Lipps, telling the press that the investigation was ongoing and that it was “too early” to completely rule out her involvement. An official apology did not come until late March 2026, roughly three months after her release in December 2025.

The Broader Pattern

The incident in North Dakota is not an unprecedented anomaly. Instead, it fits into an established pattern of wrongful detentions driven by algorithmic identification. In Detroit, police wrongfully arrested Robert Williams after facial recognition software incorrectly flagged his driver’s license, an error that eventually cost the city $300,000 in compensation. A similar misstep in New Jersey put Nijeer Parks behind bars following a digital misidentification, which ultimately led to a $150,000 settlement.

These cases point to a much broader issue in modern law enforcement. The core problem is not just that the software occasionally gets it wrong. The real danger lies in human institutions relying on these tools too eagerly. When investigators take a computer’s probabilistic guess as a fact, they strip away the safeguards of traditional police work. The lesson is straightforward: technology might generate the lead, but it is the human decision to skip basic verification that actually puts innocent people in handcuffs.

The Question of Liability

When assessing the legal fallout, the question of liability inevitably points toward human decision-makers rather than the software itself. The primary targets for civil litigation would likely be the City of Fargo and the specific detectives who handled the investigation. An algorithm cannot swear out a warrant or dispatch a tactical team; it merely generates a statistical match. It was human officials who made the active choice to rely on that output while skipping the fundamental step of independently verifying the suspect’s whereabouts.

Looking ahead, it seems unlikely that this dispute will ever reach a courtroom. Municipalities facing this level of exposure typically push for a quiet, substantial settlement rather than risk the public embarrassment and exhaustive scrutiny of their investigative practices that a trial would bring. Considering that earlier misidentification cases involving only brief detentions yielded payouts of up to $300,000, the financial stakes here are far higher. With Lipps enduring nearly six months of wrongful imprisonment, the duration of her detention alone suggests that any eventual settlement could exceed those seen in earlier algorithmic misidentification cases.

Technology Can Suggest, Humans Must Decide

The ultimate takeaway from the Fargo investigation is not that artificial intelligence has no place in modern law enforcement. When utilized correctly, algorithmic tools can be effective at processing vast datasets to identify patterns and generate preliminary leads. The critical failure occurs when a tool’s output is elevated from a statistical suggestion to an undeniable conclusion.

Technology can calculate probabilities, but it cannot – and should not – deliver justice. That burden rests firmly on the investigators who wield it. Outsourcing critical thinking to a machine bypasses the fundamental safeguards designed to protect individuals from unwarranted state action. Artificial intelligence can certainly point investigators in a specific direction, but the foundational duty to verify facts, test alibis, and protect innocent people remains an entirely human responsibility.

References

1. Fargo PD under scrutiny after woman flagged by AI facial recognition is jailed for months – Bring Me The News
2. Tennessee grandmother jailed after AI facial recognition error links her to fraud | Tennessee | The Guardian
3. US Woman Wrongly Imprisoned For 6 Months Due To Faulty Facial Recognition
4. Sheriff says email shows Fargo Police knew of Angela Lipps arrest months earlier
5. Fargo police chief apologizes for mistakes in AI-aided arrest | MPR News

We have just released a major update to Elcomsoft Distributed Password Recovery. While the release notes might simply say “migrated to 64-bit,” the reality under the hood is far more complex and significant. This is not a cosmetic update or a simple recompile; it is a fundamental architectural shift necessitated by the evolution of GPU hardware. Put simply: if you want to use the latest NVIDIA RTX 50-series Blackwell GPUs for password recovery, you can no longer use 32-bit code.

Here is why we did it, why it took so long, and why it matters for your forensic lab.

The introduction and evolution of hardware acceleration

For years, the highest performance in password recovery could be achieved by utilizing SIMD (Single Instruction Multiple Data) hardware – ranging from professional accelerators to consumer video cards powered by AMD and NVIDIA GPUs. In early 2007, we developed a method to accelerate password recovery using GPU hardware, a technology that would forever change password recovery. At a time when GPUs were thought of purely as graphics engines, Elcomsoft engineers found a way to pair them with CPUs to dramatically accelerate cryptographic calculations. This discovery came just as NVIDIA officially released CUDA – a parallel computing platform that allows software to offload computations onto GPU hardware. It was the first toolkit to open GPUs to general-purpose computing. Together these developments opened the door to much faster attacks on consumer hardware.

Since then, we’ve been using CUDA exclusively to work with NVIDIA GPUs. Back then, the entire code base was 32-bit; 64-bit compute on consumer hardware was largely unheard of. Eventually, 64-bit architecture started gaining traction in the consumer space, but we continued developing Distributed Password Recovery in 32-bit. Why? Because it just worked, and we didn’t see a real benefit in switching to a different code base. Spoiler: we still don’t. 64-bit instructions don’t magically accelerate things that don’t require huge memory pages – and password recovery is not one of the things that benefits from 64-bit instructions directly. Yet, the indirect benefit is clear.

NVIDIA has been signaling the exit from 32-bit compute for a long time. They deprecated 32-bit x86 CUDA support back in 2018 with CUDA 10, and removed it in CUDA 11. However, the real “hard stop” has arrived with the Blackwell architecture (RTX 50 series), which requires CUDA 12.8 or newer. These new GPUs and the accompanying CUDA 12.8 toolkit have dropped support for 32-bit compute applications entirely. You cannot run a 32-bit CUDA kernel on a Blackwell GPU; the driver simply won’t allow it.

For a long time, we maintained EDPR as a 32-bit application because it “just worked” on the hardware available at the time (Ampere, Ada Lovelace). But with the arrival of Blackwell, we faced a binary choice: stay 32-bit and lose support for all future NVIDIA hardware, or rewrite the entire engine for 64-bit. We chose the latter.

Under the hood: the EDPR architecture

To understand the scale of this migration, you have to look at how Elcomsoft Distributed Password Recovery is built. The system consists of three distinct components:

• The Server: This acts as the command center. It manages the queue, breaks password recovery jobs into manageable chunks, and distributes them to available clients.
• The Console: The GUI where the investigator sets up attacks, configures masks, and monitors progress.
• The Agents: These are the workers. They run on the network workstations (potentially including the local machine), receive the chunks from the server, perform the actual brute-force or dictionary attacks, and report the results back.

The Agent is where the heavy lifting happens, and crucially, where the GPU acceleration lives. This is where we hit the complexity.

The plugin problem

EDPR does not use a monolithic engine for all file formats. Instead, it uses a plugin architecture. We have over 160 discrete plugins, each designed to handle a specific data format – whether it’s a ZIP archive, a RAR5 file, a BitLocker volume, or an iOS backup.

Each of these plugins is highly optimized. In password recovery, efficiency is everything; a 5% drop in speed can mean adding days to a recovery job. To achieve maximum throughput, many of these plugins were written with heavy use of inline assembler and low-level optimizations specifically tuned for 32-bit registers and instruction sets.

When NVIDIA removed 32-bit support, we couldn’t just hit “Recompile” in Visual Studio and target x64. The inline assembler code simply does not port over. The 64-bit architecture brings more registers and a different calling convention, but it also invalidates the decades of hand-tuned 32-bit assembly we had relied on.

The migration struggle

We started working on the 64-bit port immediately after NVIDIA announced the end of 32-bit support, but the process was grueling. We had to take each of those 160+ plugins, strip out the 32-bit assembly, and rewrite the computational kernels for 64-bit.

This introduced two major challenges:

• Rewriting: Writing optimized 64-bit code from scratch for hundreds of algorithms is time-consuming.
• Regression testing: In some cases, the initial 64-bit ports were actually slower than their 32-bit predecessors. We had to spend months profiling and re-optimizing specific plugins to ensure that the move to 64-bit didn’t result in a performance penalty on older hardware. Even today, some 64-bit plugins still show regression compared to their 32-bit counterparts as direct code migration just does not give the same level of optimization.

There were moments where we saw regressions on specific hash types because the 64-bit compiler optimizations didn’t behave exactly as our hand-tuned 32-bit ASM did. We had to manually intervene to bring the speed back up. That takes time. A lot of time.

The result: ready for RTX 5090

The result of this refactoring is the new 64-bit build of Elcomsoft Distributed Password Recovery. By moving the code base to 64-bit, we have unlocked native support for the latest CUDA and the NVIDIA Blackwell architecture.

If you secure an NVIDIA GeForce RTX 5090 or 5080 for your lab, you can now utilize it fully with EDPR. The new code can communicate directly with the latest drivers, utilizing the massive parallel throughput of the new cards. This update also future-proofs the tool. With Intel and AMD compute frameworks also being 64-bit only, EDPR is now aligned with the entire GPU acceleration ecosystem.

We are currently running extensive benchmarks comparing the RTX 4090 vs the RTX 5080 and RTX 5090 on this new build. Initial results show significant gains in high-iteration formats like VeraCrypt and specialized hash types. We will publish those numbers in a follow-up post.

Finally, it is worth emphasizing that no matter how well we optimize our code or how powerful the hardware becomes – even with thousands of high-end GPUs at your disposal – certain modern encryption algorithms simply cannot be defeated by brute force alone. In these cases, a more targeted approach is required. This begins with forensic triage using tools like Elcomsoft Quick Triage, which can instantly aggregate saved credentials from a live system to find “low-hanging fruit.” Beyond that, successful recovery often depends on building a detailed suspect profile to move from “cold” attacks to “smart” ones. By leveraging personal data to create targeted dictionaries, applying complex masks, and using rule-based mutations, investigators can focus their computational power on the most likely password candidates rather than wasting cycles on a mathematically impossible search.

Benchmarks

Many storage devices and adapter boards look alike. When holding a module with a connector that looks suspiciously like the M.2, how do you know exactly what you are dealing with? Is that M.2 board a SATA drive, a fast NVMe device or a Wi-Fi/Bluetooth combo? Will a drive removed from an Apple computer work in a simple mechanical adapter, or will it require the original Apple device to access? A physical connector does not guarantee the underlying technology.

While the NVMe protocol powers everything from standard consumer M.2 slots to enterprise U.2 and EDSFF devices, the hardware world is full of deceptive lookalikes. For example, the proprietary raw NAND modules found in recent Apple hardware might look like standard NVMe disks, but they are completely unreadable outside their host system because they lack an onboard controller. In this article, we will break down the physical form factors that actually host true NVMe storage and help you spot the proprietary lookalikes.

NVMe Form Factor & Protocol Support Table

Let us start with a table.

Technical Notes

The M.2 form factor is the de facto standard for consumer drives. However, an M.2 board can host a variety of hardware and support a range of protocols, visually identifiable by the configuration of physical cutouts (the “keys”). Below is an image of a typical M.2 Key E module.

The Apple 2013-2019 connectors. Apple SSDs from the 2013-2019 period use multiple proprietary connector types, most commonly 12+16-pin and later 22+34-pin designs. However, these connectors do not map cleanly to specific product lines or years, and both types may appear across overlapping generations. Earlier 12+16-pin modules were typically PCIe AHCI-based, while later designs transitioned to NVMe; connector type alone is not sufficient to determine protocol support. The newer 22+34-pin connector is associated with later NVMe-based SSDs. Exact model-year compatibility must always be verified; refer to Apple Proprietary SSDs: Ultimate Guide to Specs & Upgrades | BeetsBlog for details. 22+34 pin (top) and 12+16 pin (bottom) modules:

The Mac Mini “SSD”. The removable storage modules in modern Apple Silicon hardware (like the M4 Mac Mini or Mac Studio) are not NVMe drives, despite physically resembling a stubby M.2 SSD. They consist entirely of raw NAND flash chips. The actual NVMe storage controller is integrated directly into the Apple M-series SoC, meaning the physical connector only transmits raw NAND signals. As a result, these modules will not “work” outside of Apple hardware, while direct readouts will be likely fruitless due to encryption. A Mac Mini (2024) storage module (courtesy of iFixit):

Samsung NF1 (formerly NGSFF). Designed as a “wider M.2” (30.5mm x 110mm) to accommodate multiple rows of high-capacity NAND chips for 1U servers. While it introduced enterprise features like hot-swapping and dual-port support, it failed to gain broad industry support. It is now considered a legacy format that never achieved the reach of the universally adopted EDSFF standard.

Key A+E NVMe Drives. The A+E keyed connectors were originally designed to host Wi-Fi/Bluetooth adapters. They are commonly used in ultrabooks, NUC PCs, and many desktop computer boards, typically featuring one or two PCIe lanes. Niche, third-party M.2 Key A+E NVMe drives exist, providing a hardware solution for adding a dedicated NVMe drive to space-constrained systems (like mini-PCs, homelab routers, or NAS builds). They have severe bandwidth limitations as standard M-Key slot provides 4 lanes of PCIe (x4), whereas an A+E slot typically provisions only PCIe x1 or x2. In addition, system firmware compatibility can be inconsistent. Some older environments may employ hardware whitelisting (restricting the slot to specific Wi-Fi modules) or lack the necessary NVMe drivers to boot the OS from the A+E interface. Yet, the existence of such storage devices proves the point: you cannot assume that a given board is a Wi-Fi/Bluetooth combo just because it is keyed A+E.

Conclusion

Things are not always what they look like. An M.2 board can be a storage device or a Bluetooth adapter, and a Wi-Fi-card slot can host an NVMe drive. The “22+34 pin” connectors are actually “12+16”; they can be either PCIe AHCI or NVMe, and will typically work in a third-party adapter. Newer Apple storage boards look like a stubby M.2 SSD – but they aren’t. Instead, they just host raw NAND chips, making the data entirely inaccessible outside of the host Apple device.

Picture this: you just dropped $1,300 on a brand-new, top-of-the-line Android flagship. You unbox it, peel off the plastic film, boot it up, and get ready for the daily grind. But before you can even sync your contacts, you notice the app drawer is already cluttered with unsolicited apps. If you think this is a problem exclusive to fifty-dollar burner phones bought at a gas station or cheap Chinese handsets obtained from an online shopping site, think again. We’ve seen this corporate hoarding disease infect even the highest tiers. Just look at the new Samsung Galaxy S26 Ultra; a clean setup of a 512GB model immediately sacrifices over 40GB to system files and third-party apps you never asked for. To be clear, you get zero say in the matter – they are pre-installed without a single prompt. You pay top dollar for premium hardware, and the manufacturer still treats your device like a subsidized billboard.

But high-profile annoyances from giants like Meta and Microsoft are just the visible tip of the iceberg. The real problem is hidden slightly deeper in the supply chain: the pre-installed “utility” apps.

We’re talking about system cleaners, alternative keyboards, memory optimizers, and smart remotes. Why are they baked into your firmware? Pure, shortsighted corporate greed. Hardware manufacturers willingly partner with third-party software vendors, trading their brand reputation and your device’s attack surface for a negligible pre-installation bounty. OEMs actively compromise the integrity of millions of devices for fractions of a cent per unit.

To scrape together pennies on the production margin, manufacturers grant these dubious vendors the absolute holy grail of Android persistence. By baking these “utilities” directly into the factory image, the OEM implicitly vouches for them. They fly below the radar of your due diligence and bypass the standard user-consent gauntlet, inheriting deep system access and unshakeable persistence simply by existing on the device right out of the box.

At this point, there are literally millions of devices running a highly privileged, un-deletable piece of third-party code fully controlled by an external vendor who eventually needs to show a return on investment.

What could possibly go wrong?

The “Trusted” Partition

This is where Android’s security model meets the timeless urge to squeeze one more coin out of the hardware. When an OEM cuts a deal with a third-party software vendor, the app (or its stub) gets baked straight into the firmware. Usually that means /system/app; if the vendor needs deeper integration, maybe even /system/priv-app.

And that matters. A pre-installed app is not just another app. It starts life inside the factory image, wrapped in OEM trust, and in some cases gets privileges that ordinary user-installed software can only dream about. Not because it earned them, of course. Just because someone in a meeting decided the pre-install check was worth more than the long-term headache.

To save space, manufacturers sometimes do not preload the full app. They ship a stub: a placeholder APK with an icon, some metadata, and a digital signature. Later, during setup, that stub pulls down the payload from Google Play or the OEM’s own app store. Depending on how the package is signed and allowlisted, the downloaded version can continue enjoying some of the trust and privileges attached to the factory stub.

The Update Hijack Mechanism

So what happens after the phone leaves the factory? At shipment time, the pre-installed app may be harmless and polished just enough to survive the OEM’s review. Months later, that same vendor still controls the signing keys. So they can ship an update through Google Play, and Android will accept it as the same app as long as the signature checks out – meaning that at any point in the future, that developer can push an updated APK through the Google Play Store. The modified app may then go on with the same permissions, trust, and privileged treatment already granted by the OEM. In practice, it means that the OEM’s initial security review becomes a lot less reassuring, effectively turning a one-time decision into a long-term channel for shipping arbitrary privileged payload onto the user’s device.

The Metamorphosis: From Useful Tool to Exit Strategy

The life cycle of a pre-installed Android utility is depressingly predictable. It usually starts with a genuinely useful tool, a massive user base, and a lucrative OEM contract. But eventually, the native OS simply gets good enough to make third-party memory cleaners and IR remotes completely obsolete. Faced with an existential crisis and investors demanding a return, the developers become tempted to execute their exit strategy – which, in many cases, is a pivot toward aggressive monetization. At that exact moment, the phone they were originally supposed to optimize stops being the client and becomes the product – just raw material to be aggressively mined for lock-screen ad impressions, background data collection, and click-fraud revenue. Here is what that downward spiral looks like in practice.

ES File Explorer: from indispensable tool to unauthenticated LAN honeypot

I genuinely used to use this application back in the day, but the tragic arc of DO Global’s ES File Explorer is a masterclass in burning user goodwill. Facing pressure to monetize a massive base of over 100 million active installations, the developers pushed an update introducing a “Smart Charge” feature that forcefully hijacked the user’s lock screen whenever the device was plugged in, replacing it with deceptive metrics and intrusive advertisements. As if aggressively rendering devices unusable wasn’t enough, the monetization drive ultimately compromised the app’s foundational security architecture. As BleepingComputer reported, the developers quietly spun up a completely unauthenticated, hidden HTTP web server on local TCP port 59777 (CVE-2019-6447) every time the application launched. Because there were zero authentication mechanisms, anyone connected to the same public Wi-Fi network could seamlessly interface with the app to map the victim’s device, silently extract personal files, and remotely execute commands.

Clean Master & QuickPic: from device optimizer to silent click-fraud syndicate

Cheetah Mobile achieved a healthy market share by cutting deals with multiple OEMs to embed its “Clean Master” utility into factory firmware, but behind the facade of device optimization, it was fundamentally engineered as a data monetization entity. Instead of clearing system caches, the updated applications operated silently in the background, utilizing their expansive system permissions to run a massive advertising fraud scheme that injected fake synthetic “clicks” to fraudulently siphon millions in referral bounties. The syndicate later expanded their software portfolio; they famously acquired the beloved, lightweight gallery app QuickPic, solely to strip-mine its fiercely loyal user base. As exposed in this Android Police investigation, Cheetah Mobile pushed updates that instantly destroyed QuickPic’s core value. The end result? QuickPic was swept up in the broader Google ban of Cheetah Mobile products in 2018, though brief, bug-ridden re-releases attempted to bypass the block.

TouchPal: from swipe-typing pioneer to an adware nightmare

A third-party keyboard inherently requires an absolute, unshakeable trust between the hardware manufacturer and the software vendor, simply because it possesses the capability to intercept every single password and private communication entered by the user. CooTek’s TouchPal keyboard thoroughly violated this trust after securing pre-installation agreements on premium devices from over 50 manufacturers, including HTC. The developers secretly integrated a heavily obfuscated advertising plugin known as “BeiTaAd,” an absolute masterpiece of malicious engineering designed to aggressively evade automated security scanners. As the original Lookout threat research detailed, the plugin would lie completely dormant for 24 hours to two weeks after an update. It would then wake up to forcefully hijack the lock screen and trigger incredibly loud out-of-app audio and video advertisements, rendering the mobile device nearly unusable even while asleep in the user’s pocket.

Peel Smart Remote: from hardware companion to panicked adware engine

Peel Smart Remote started out as a genuinely useful IR remote control app, deeply integrated into the firmware of millions of Android phones and effectively turning them into universal remotes through their built-in IR blasters. Then the smartphone industry moved on. Manufacturers started dropping IR hardware, Peel’s original value proposition collapsed, and management responded with the sort of quiet panic that usually produces terrible product decisions. The updated versions turned the once-useful utility into an intrusive adware engine, using its pre-installed foothold to overlay advertisements on the lock screen and disrupt normal device use. As Android Police noted, the app began displaying full-screen ads, opening random spam websites, and modifying the lock screen without making it especially obvious what was causing the mess. In other words, a classic case of a pre-installed utility degenerating into nuisanceware once the original business stopped making sense.

The True Cost of “Free” Software

At the end of the day, this isn’t a story about genius-level hackers pulling off the heist of the century. It’s just a boring, predictable failure of corporate economics – a classic “what could possibly go wrong” scenario. When user consent gets tossed out on the factory assembly line, the whole Android security model falls apart. You can’t even rely on automated scanners like Google Play Protect to save you. They are built to spot rogue malware trying to break in, not to evict a “trusted” partner who was explicitly handed the keys to the vault by the manufacturer. Trading hardware integrity for a fraction of a cent per unit is simply bad business.

The root cause here isn’t broken code or inherent design flaws; it’s just your usual, boring corporate greed. Hardware manufacturers have perfected the trick. They pocket the upfront cash, cement the third-party clutter into an undeletable system folder, and then conveniently look the other way when that same app pivots to click-fraud. The manufacturer gets to plead ignorance, the app developer cashes out, and you are left holding a hijacked phone. You might have bought the phone, but make no mistake: you are still the product.

This article concludes our series on Windows forensic artefacts and the role they play in real-world investigations. Over the past several weeks, we looked at evidence sources that help investigators understand activity at the system level, from Windows Event Logs and the Windows Registry to file system traces stored under C:\Windows and C:\ProgramData. Those artefacts are indispensable when reconstructing the broader picture: system startup and shutdown, service activity, software installation, persistence mechanisms, and signs of compromise affecting the machine as a whole. Yet system-wide telemetry has an obvious limitation. It can tell us that something happened, but not always who was behind it. This is where the focus shifts from the operating system to the individual user.

Modern Windows systems are designed to isolate user environments from the core OS. Documents, downloads, application caches, cloud sync data, shortcuts, thumbnails, temporary files, and countless other traces of day-to-day activity are pushed into the user profile. In that sense, C:\Users\<username> is perhaps the closest thing Windows has to a behavioral map of a specific person using that system.

In this final installment, we move away from system-level evidence and into user-specific artefacts stored under the profile directory. This is where attribution becomes more precise, where ordinary folders such as Desktop, Downloads, and Documents contain data created or acquired by the user, and where hidden application data can reveal what a user opened, downloaded, edited, synchronized, or tried to remove.

C:\Users vs. %USERPROFILE%

Before looking at specific artefacts, let’s make one practical distinction: user profile data is accessed differently on a live system and in offline analysis. The C:\Users directory is the physical, hardcoded root for user profiles on a standard Windows installation. In forensic work, that path is most often associated with dead-box analysis. Once an examiner mounts a forensic disk image, this static directory offers a complete view of every profile stored on the system, not just the account that was active at the moment the machine was seized. That wider view matters in real cases, where disabled accounts, long-forgotten profiles, or attacker-created local users may still hold useful evidence.

%USERPROFILE%, on the other hand, is a live environment variable that resolves to the home directory of the user currently logged into that session, which makes it useful during live system analysis and rapid triage. Investigators can use %USERPROFILE% to point scripts and collection tools at the active account. In practice, that makes it a natural fit for PowerShell scripts and other automated workflows.

Although this article focuses on file system artefacts, we have to mention the user’s registry hives. The two key files are %USERPROFILE%\NTUSER.DAT and %USERPROFILE%\AppData\Local\Microsoft\Windows\UsrClass.dat. The first is the main per-user hive, storing user-specific settings, execution traces, and file access history. The second contains valuable shell-related artefacts such as ShellBags and MUICache entries, and is particularly important on modern Windows systems. We will leave those hives aside here to keep the focus on file system evidence, but they should always be acquired together with the rest of the profile. For a deeper discussion, see our earlier article on the Windows Registry.

Caveat: C:\Users is only the default profile root and must not be assumed in every installation. The system-wide base path for user profiles is recorded in the Registry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory, while a specific user’s actual profile path (%USERPROFILE%) is defined per SID at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID>\ProfileImagePath. In other words, profiles may be redirected to another volume, so analysts should verify the registered profile paths instead of relying on the presence of a C:\Users folder alone.

Predefined User Folders and Native Applications

When Windows creates a user profile, it also creates a set of default folders under C:\Users\<username>. To the user, these are convenient save locations. To an investigator, they are some of the most productive artefacts on the system. Windows, browsers, email clients, Office apps, and built-in tools all write to these folders by default, which makes them a practical record of what the user downloaded, opened, edited, staged, or tried to remove.

The Downloads folder

What it is: Downloads, typically located at %USERPROFILE%\Downloads, is the default save location for files arriving from the Internet, email, messaging apps, and local networks.

Forensic value: This is often where a compromise first touches disk. The file itself matters, but the hidden metadata can matter even more. On NTFS volumes, Windows may attach a Zone.Identifier alternate data stream, which marks the file as a Web download. That stream can preserve the security zone, referrer URL, and direct host URL of the downloaded file. Even if the payload is later renamed, that metadata may still point to the phishing page, malware host, or delivery server that brought it onto the endpoint. Missing or stripped Zone.Identifier data on executables, scripts, or archives can also be meaningful, as removing the Mark of the Web is a common way to suppress security warnings. Investigators should also check %USERPROFILE%\Links, which may contain Downloads.lnk pointing back to this folder.

The Desktop folder

What it is: The Desktop is the user’s visible workspace, holding files, folders, and shortcuts shown directly in the shell. Depending on configuration, it may be stored locally at %USERPROFILE%\Desktop or redirected into OneDrive at %USERPROFILE%\OneDrive\Desktop.

Forensic value: People use the Desktop as a scratchpad, and attackers do too. In insider cases, it is often used to stage files before compression, copying, or exfiltration. In intrusion cases, it commonly holds payloads, scripts, and ransom notes placed where the user will see them immediately. Even when the original file is gone, a leftover .lnk shortcut on the Desktop may still show that the user had direct access to it. A second place worth checking is %USERPROFILE%\Links, which may contain Desktop.lnk pointing to the active Desktop location.

The Documents folder

What it is: Documents, usually stored in %USERPROFILE%\Documents, remains the default save location for Office files, PDFs, text files, exports, and other work product.

Forensic value: In many cases, this is where the data of interest actually lives. That alone makes it a prime target in theft and ransomware incidents. It can also contain useful secondary traces. One example is the temporary Office lock file, usually prefixed with ~$. If one of these files is left behind, it can show that the corresponding document was open and being edited when the system crashed, was shut down abruptly, or the session ended unexpectedly.

Pictures, Music, and Videos

What it is: These are the default Windows libraries for media storage and browsing, typically located at %USERPROFILE%\Pictures, %USERPROFILE%\Music, and %USERPROFILE%\Videos.

Forensic value: Media folders are easy to skip in enterprise cases, but they can be highly valuable. One reason is Thumbs.db. In older Windows versions, and still in some network-folder scenarios, Windows stores thumbnail previews in hidden Thumbs.db files inside image folders. Those thumbnails may survive after the original files are deleted, giving investigators proof that a given image once existed in that location. Large media folders can also provide cover for hidden payloads or stolen data concealed inside otherwise ordinary-looking files.

The Recent folder and LNK files

What it is: Windows maintains a hidden Recent folder at %APPDATA%\Microsoft\Windows\Recent (physically %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Recent). When a user opens a document, picture, or application, Windows often creates a shortcut file pointing to that target and stores it there.

Forensic value: These .lnk files are some of the most useful profile artefacts available. They often survive after the original file has been deleted or the USB drive has been disconnected. More importantly, an LNK file is not just a pointer. It can preserve the original target path, target timestamps, and storage-device details such as volume serial number and drive type. That makes Recent especially useful when the goal is to prove file access, not just file presence.

The Favorites folder

What it is: Favorites, typically located at %USERPROFILE%\Favorites, is a legacy shell folder originally used by Internet Explorer to store bookmarked web links and shortcuts.

Forensic value: While less prominent on modern systems, this folder still appears on many Windows installations and can retain useful historical traces. In older user profiles, it may preserve bookmarked URLs, manually saved shortcuts, or application-created links that help reconstruct browsing habits, user interests, or access to specific internal and external resources. In some cases, its value is less about current activity and more about persistence: artefacts left in Favorites can survive browser changes and remain in the profile long after the original workflow has been abandoned.

Microsoft OneDrive

What it is: OneDrive is built into Windows 10 and 11 as the default cloud sync engine. Its visible sync root is usually %USERPROFILE%\OneDrive, and it supports local files, cloud-only placeholders, and Files On-Demand.

Important: Partial sync is a real issue, affecting both offline and live system analysis – just in different ways. We strongly recommend familiarizing yourself with the issue by reading The Cloud Gap: Forensic Triage vs. Disk Imaging in the Age of On-Demand Sync.

Forensic value: OneDrive extends the user profile beyond the local disk. Investigators should look in three places. The first is the visible sync root, usually %USERPROFILE%\OneDrive, where cloud-only files may appear as placeholders. Even without the full file body on disk, those entries can still show that the user knew about the file and had access to it. The second is %LOCALAPPDATA%\Microsoft\OneDrive\logs, which stores .odl synchronization logs. These can help reconstruct uploads, downloads, renames, deletions, and, in some cases, sharing activity. The third is %LOCALAPPDATA%\Microsoft\OneDrive\settings, where files such as UserCid.dat and SyncEngineDatabase.db can link the local Windows account to a Microsoft identity and expose the structure of synchronized cloud data.

Windows 11 Notepad

What it is: On Windows 11, Notepad is no longer a bare-bones text editor. It now supports session persistence and can restore unsaved tabs.

Forensic value: That feature leaves a useful artefact behind. Notepad stores active tab contents in binary .bin files under %LOCALAPPDATA%\Packages\Microsoft.WindowsNotepad_8wekyb3d8bbwe\LocalState\TabState. In practice, that means unsaved text may still be recoverable after the user closes the app without saving. Notes, pasted credentials, IP lists, and command fragments can all survive in TabState, turning what used to be volatile user activity into file-system evidence.

Paint, WordPad, and other lightweight native editors

What it is: Tools such as Paint, WordPad, and the legacy Write application are basic editors that are present on many Windows systems by default.

Forensic value: Their value lies in how often they are used precisely because they are already there. Paint can leave cache-related traces in AppData while an image is being edited, which may help show that a screenshot or graphic was manipulated locally. WordPad and Write can generate temporary files and .lnk traces in the Recent folder when documents are opened or edited. In practice, that may be enough to show that a user viewed or modified a file without ever installing third-party software.

AppData and Dot-Prefixed Folders

%USERPROFILE%\AppData has the hidden file-system attribute set. The goal is not to conceal it from the user or the examiner, but to reduce visual clutter in File Explorer. This is where Windows and applications store configuration data and other files not intended for routine user access: settings, caches, session state, temporary files, logs, browser data, and similar artefacts generated during normal use. It is also one of the richest sources of user-attributed evidence on the system, regardless of whether the software is built into Windows or installed separately.

AppData is divided into three subfolders with distinct roles: Roaming, Local, and LocalLow. That split reflects how Windows treats user data. Some data is meant to follow the user between domain-connected systems, some stays with a specific machine, and some is written by sandboxed low-integrity processes. Forensic analysis of these folders helps separate user behavior that is portable from artefacts tied to one endpoint or one restricted execution context.

The Roaming subfolder

What it is: %APPDATA%, which resolves to %USERPROFILE%\AppData\Roaming, stores data intended to follow the user across multiple domain-connected systems. In a traditional Active Directory environment, this can include application preferences, bookmarks, dictionaries, and other portable settings. Notably, in standalone or workgroup setups, Roaming still exists and still holds the same application data – it just never leaves the machine.

Forensic value: Roaming often ties application activity to the user rather than to a single machine. It commonly stores core profiles for browsers, messaging tools, FTP clients, and other communication software, making it a useful source of chat histories, saved credentials, bookmarks, and application settings. In domain environments, the same synchronized artefacts appearing across multiple endpoints can help link repeated activity to the same user account. Roaming is also a common location for malware persistence. Standard users can write there without administrative rights, making it a practical drop point for scripts, keyloggers, loaders, and disguised executables (double extension, icon spoofing, masquerading as known app subfolders and so on). Unexpected binaries in Roaming deserve attention.

The Local subfolder

What it is: %LOCALAPPDATA%, or %USERPROFILE%\AppData\Local, stores data tied to the specific machine. It does not roam with the user, even in a domain environment. Windows and applications use it for large caches, temporary content, update packages, installer remnants, and other data that is too bulky or too device-specific to sync efficiently.

Note: %LOCALAPPDATA%\Programs: this is where user-level application installs typically land (no UAC prompt/admin rights required), making it a common drop location for both legitimate portable apps and malware that needs persistence without elevation.

Forensic value: Local is often where device-specific activity is recorded. Modern browsers keep much of their cache data here, which can help reconstruct browsing activity, recover fragments of viewed content, and trace downloads in more detail than the visible Downloads folder alone. Local also contains important Windows artefacts, including the centralized thumbnail cache under %LOCALAPPDATA%\Microsoft\Windows\Explorer. Those Thumbcache databases can show images viewed on the system even when the original files are gone. Another high-value location is %LOCALAPPDATA%\Temp, where installers, updaters, and many malicious payloads unpack working files. Timestamps in Temp can help build a detailed execution or installation timeline. Notably, %TEMP% and %TMP% typically resolve there, but some users may override their locations (e.g. to point to a scratch disk).

The LocalLow subfolder

What it is: %USERPROFILE%\AppData\LocalLow is separate from Local for security reasons. It is the designated write location for processes running at low integrity under Windows Mandatory Integrity Control. In practice, sandboxed or partially isolated applications often use LocalLow instead of the standard Roaming or Local paths.

Forensic value: LocalLow is most relevant in cases involving browsers, app sandboxes, or exploit chains. Low-integrity processes have limited write access, so their caches, temporary files, and session artefacts often end up here. That makes LocalLow useful for tracing protected browser activity, low-integrity execution, and the early stages of web-based compromise. If an attacker gained an initial foothold through a browser sandbox or another constrained process, traces of that activity may remain in LocalLow before privilege escalation or sandbox escape shifted activity elsewhere.

Configuration folders: the dot-prefixed directories

What they are: Windows traditionally stored most per-user settings in the Registry and AppData, but modern cross-platform tools increasingly use Unix-style configuration files and folders in the root of the user profile. Common examples include %USERPROFILE%\.ssh, %USERPROFILE%\.aws, %USERPROFILE%\.vscode, and %USERPROFILE%\.gitconfig. These locations often store authentication material, connection history, and cloud or development tool settings.

Forensic value: Dot-prefixed artefacts can be highly significant. The .ssh folder may contain private keys such as id_rsa or id_ed25519, along with known_hosts, which records servers the user connected to. That can help map lateral movement and identify access to internal Linux systems or cloud infrastructure. The .aws folder may contain plaintext access keys and secret tokens used by AWS command-line tools. .gitconfig can link the local Windows account to a developer identity through names, email addresses, and repository settings. The .vscode directory can expose workspace settings, remote connection history, and extension data, helping show what repositories were accessed and whether a malicious extension was used. In incident response, these folders often connect a compromised workstation to activity in source code systems, cloud environments, or remote servers.

Conclusion

User profile artefacts are some of the most revealing traces on a Windows system, but they rarely make sense in isolation. A file in Downloads, a shortcut in Recent, a thumbnail cache entry, a OneDrive sync log, or a leftover Notepad tab snapshot may each tell only part of the story. The real value comes from correlation. Investigators have to connect visible folders, hidden AppData stores, shell artefacts, cloud traces, and configuration files into a single timeline that explains not just what happened on the machine, but which user likely did it.

That is what makes C:\Users such an important forensic location. System-wide telemetry can show that an event occurred, that software was installed, or that a payload executed. The user profile is where those technical facts start to become attributable. It is where downloaded files meet recently opened documents, where application caches confirm user activity, and where synchronized cloud data or stored authentication material can extend the investigation beyond the local endpoint. During incident response, this kind of granular, localized evidence is often the difference between observing suspicious activity and confidently tying that activity to a specific human operator.

With this article, we conclude our planned series on Windows artefacts. We began with Event Logs and the Registry, moved through file system artefacts under C:\Windows and C:\ProgramData, and finished with the user profile, the part of the system where technical activity and human behavior intersect most directly. Taken together, these sources form a practical map for Windows forensic analysis: broad system telemetry for context, and user-level artefacts for attribution.

Previous articles in the series:

1. Forensic Analysis of Windows 10 and 11 Event Logs (ElcomSoft blog)
2. Investigating Windows Registry (ElcomSoft blog)
3. Investigating Windows File System Artifacts Under C:\Windows (ElcomSoft blog)
4. Windows File System Artefacts Under C:\ProgramData (ElcomSoft blog)

Many thanks to the authors and researchers of the prior work cited below. Their research, writeups, and public tooling helped shape both this article and the broader DFIR community.

1. About User Profiles (Microsoft Learn)
2. Folder Redirection and Roaming User Profiles in Windows and Windows Server (Microsoft Learn)
3. Windows Forensic Artifacts User Activity (Elite Digital Forensics)
4. Mark of the Web Bypass (Red Canary Threat Detection Report)
5. Thumbs.db (Forensics Wiki)
6. Windows thumbcache (Forensics Wiki)
7. Lnk (Forensics Wiki)
8. Reading OneDrive Logs (Yogesh Khatri’s forensic blog)
9. OneDrive Forensics: Investigating Cloud Storage on Windows Systems (CyberEngage)
10. Exploring windows artifacts notepad files (u0041)
11. What makes Windows 11 interesting from a digital forensics perspective (Securelist)

Spoiler: you are probably already using AI agents, even if marketing hasn’t yelled at you about it yet. Forget the dark ages of 2023 when large language models (LLMs) just confidently hallucinated fake server logs and nonexistent IP addresses. Today’s AI can spin up a virtual environment, navigate web pages, scrape data, and logically process what it finds. Let’s cut through the noise and talk about what “agents” actually are, how “Deep Research” operates, and how to spin up your own pocket investigator that doesn’t come with corporate safety bumpers.

From Guessing to Doing

Remember the old ChatGPT 3.5? It relied entirely on its internal, heavily compressed training data. Ask it to summarize a rare piece of malware, and it would just start guessing to fill the gaps. Ask it to count the ‘r’s in “strawberry” or strip footnotes from a forensic report, and it would fail in the classic, predictable way.

But ask a modern model to do the same, and it writes a Python script, runs it, and hands you the correct, algorithmic result. That’s an agent in action.

If you search for the definition of an AI agent, you’ll hit AWS documentation saying things like: “AI agents can take initiative based on forecasts and models of future states.” Corporate word salad. Here’s what matters:

• Tools: Functions a model can trigger (like running code or executing a search query).
• Agents: A model triggering those tools in a continuous loop, checking its own work, and correcting its course.

Deep Research: How It Actually Works

Most of the hype around agents right now is about “vibe coding.” If you’re a forensic specialist, you probably don’t care about that. What you care about is Deep Research.

Deep Research isn’t just a search query; it’s a multi-step orchestration pipeline. It takes your prompt, breaks it down, and methodically grinds through the internet. Here is the loop:

• Decomposition: You ask it to pull a history of vulnerabilities for a specific IoT router. It writes a plan: Find the manufacturer -> locate the specific firmware CVEs -> search GitHub for proof-of-concept exploits.
• Action: It triggers a search API.
• Parsing: It pulls down the HTML via a headless browser, shreds the ad banners and navigation, and keeps the raw text.
• Reflection: It reads the text and checks its work. Did it find a CVE, or just a dead forum thread? If it’s garbage, it flags the source as useless and moves on.
• Self-Correction: If it hits a wall, it broadens the search to the underlying chipset.
• Synthesis: It compiles the valid data into a coherent report with citations.

This setup limits hallucinations because the model stops relying on its internal weights to generate facts. It only uses its language capabilities to synthesize the external text it just downloaded.

However, this is cool in demos, painful in operations if you use a weak model. The orchestrator needs actual reasoning capabilities. Here’s where this breaks: if you put a lightweight, easily confused model in the driver’s seat, it will just Google the exact same useless query for three hours and drain your API credits.

Going Local: Air-Gapped and Locally Controlled

Running Deep Research locally is currently one of the most active spaces on GitHub, and it’s not just because nobody wants to burn through expensive API limits. For law enforcement and digital forensics, the cloud is often a complete non-starter due to strict safety filters and basic data custody requirements.

Try feeding a standard commercial model a messy data dump from a suspect’s phone. The second the text hits a discussion about illegal drug logistics, traces of intent to commit violence, or highly sensitive illicit material, the model’s alignment rigidly kicks in. It throws a canned “I cannot fulfill this request” error and halts your pipeline. You are trying to parse a legally acquired digital footprint, but the AI’s commercial guardrails are designed for general consumer safety, not digital forensics.

This is a known friction point. Incident responders and forensic analysts constantly run into brick walls when commercial LLM guardrails actively block the defensive analysis of malware, exploit codes, and raw criminal evidence.

Open-source models have gotten remarkably capable of handling these workloads. Models like the GPT OSS line (the 20B that can run on a potato, or the heavier 120B), the GLM 4.5 Air, and the Qwen 3.5 series are capable local orchestrators that actually know how to “think” and use tools. But out of the box, even some of these carry the same sanitized training.

Here is where community tooling catches up to forensic reality: “abliterated” models. Developers have stripped out the refusal vectors to reduce refusal behavior. Using these isn’t about embracing chaos; it’s about operator control. By deploying a local, unfiltered model, you ensure that the data stays on your local device – and that the AI will actually process the harsh realities of a criminal dataset without refusing to work halfway through a massive extraction. It keeps the investigation entirely in-house, air-gapped, fully auditable, and firmly in the hands of the examiner – exactly where the evidence belongs.

The Tooling

If you have the hardware, here is how you spin this up:

• Perplexica: An open-source clone of Perplexity. Hook it up to your local models and a local SearXNG instance (for anonymized scraping), and you have a private research engine in your browser.
• Open Deep Research (LangChain) / DeepSearcher: Heavier tools designed for massive research tasks. You point them at the web or a massive dump of internal documents, define the logic pipeline, and let them run.
• CLI Tools: Fire off a command in the terminal or open a local Web page, and tools like local-deep-research or Auto-Deep-Research methodically scrape, read, and feed data to your local model, spitting out a cited report.

Can you use AI agents in your workflow? You probably can. But should you really?

It is incredibly tempting to jump on the bandwagon, point an autonomous, uncensored research loop at a massive 500GB extraction file and tell it to go hunt for anomalies while you grab another coffee. But let’s take a step back and remember what we are actually dealing with. These tools autonomously write code, execute scripts, and scrape raw data from the absolute worst neighborhoods on the internet.

This is exactly the kind of tech that looks cool in demos, painful in operations.

If your agent decides the best way to analyze an obfuscated script found in a suspect’s downloads folder is to just execute it, or if it accidentally reaches out to a live command-and-control server while trying to parse a malicious URL, your Friday is effectively over.

Please, for the love of the chain of custody, don’t let it touch production – let alone the suspect’s machine – without containerizing the absolute hell out of the environment it uses to browse and run code. Air-gap the analysis box, strictly sandbox the execution environment, and drop any outbound traffic that isn’t explicitly required for the search tool.

Treat a local AI agent like a highly caffeinated, incredibly fast junior analyst who has absolutely zero concept of operational security. They are a massive force multiplier for open-source intelligence, threat hunting, and chewing through tedious documentation, freeing you up to do the actual brain work. They just need a babysitter.

So, pull down a local model this weekend. Break it. See how it handles a piece of your backlog. Just keep it in a very, very sturdy box.

This guide continues our ongoing series exploring Windows digital artefacts and their practical value during an investigation. Here, we turn our attention to the specific set of files located under the root path %ProgramData% (commonly C:\ProgramData\) and its subfolders. Unlike standard user profile folders, this directory typically houses system-wide data, shared application configurations, and background service caches that apply to the system as a whole. For investigators, this path offers a system-level perspective. Analyzing it can uncover historical activity, revealing events from background file transfers and software installations to Wi-Fi connections and security tool detections.

Technical Notes

Several of the databases in this directory are held open by system services. Forensically sound acquisition typically requires collecting them from a disk image or using a shadow copy (VSS) mechanism. In this article, %ProgramData% and C:\ProgramData\ will be used interchangeably; when analyzing a live system, we recommend initially deriving the physical path of the ProgramData folder by resolving the corresponding environment variable. Both methods are supported in Elcomsoft Quick Triage.

BITS Queue Manager Database (QMGR)

Background Intelligent Transfer Service (BITS) is a service used by legitimate components to asynchronously transfer large files with minimal user disruption. BITS maintains its job, file, and state data in a local queue manager database located under C:\ProgramData\Microsoft\Network\Downloader\.

On Windows 10 and later, the queue is typically stored as an ESE database (for example, qmgr.db) with accompanying log files; older systems commonly used qmgr0.dat / qmgr1.dat.

From an investigative perspective, this database holds high forensic value because it preserves a system-managed record of transfer intent and metadata. Parsing or carving this database can reveal:

• Source URLs and destination paths.
• Job names, descriptions, and user SIDs associated with the jobs.
• The presence of suspicious notification commands that execute upon job completion.
• Deleted jobs recovered from slack space or transaction logs.

Cross-correlation: To establish a verifiable timeline and confirm if a transfer actually occurred, correlate the QMGR data with the Microsoft-Windows-Bits-Client/Operational event log (Background Intelligent Transfer Service – Win32 apps | Microsoft Learn).

Windows Search Database

Windows Search Indexer accelerates local searches by maintaining an on-disk index of selected content sources, saved by default under C:\ProgramData\Microsoft\Search\Data\Applications\Windows\. Forensically, this index acts as a secondary catalogue of what the system considered searchable. It provides investigators with indexed file metadata, limited file contents, and traces of user activity or URLs.

Cross-correlation: Because “indexed” does not guarantee “executed,” cross-correlate this database with file-system timeline artefacts, application logs, or endpoint telemetry to defensibly confirm a file’s presence, access, and timing.

Windows Error Reporting (WER) Store

Windows Error Reporting gathers information about hardware and software faults, storing pending and archived reports on disk under C:\ProgramData\Microsoft\Windows\WER\.

While primarily about crashes, WER yields strong execution-adjacent signals. A report directory containing an AppCrash_* pattern and a Report.wer file is strong evidence that a given executable ran and faulted on the system. It typically includes timestamps, executable identifiers, and contextual strings about the failing module.

Cross-correlation: To establish causality, correlate WER artefacts with Application event log entries (such as “Application Error”) and any logs specific to the crashing process.

Microsoft Defender Artefacts

The following artefacts are produced by Microsoft Defender. Analyzing these files reveals threat detection history.

Microsoft Defender Antivirus Detection History

When Defender’s real-time protection detects and blocks or remediates threats, it creates DetectionHistory records under C:\ProgramData\Microsoft\Windows Defender\Scans\History\Service\DetectionHistory\.

These files offer host-native security telemetry. They contain data about detections, including the threat name, malicious file location, detection timestamp, cryptographic hashes, and (depending on the detection) initiating or associated process information.

Cross-correlation: Validate these findings by correlating them with the Microsoft-Windows-Windows Defender/Operational event log, which provides canonical event IDs for malware detection and configuration changes.

Microsoft Defender Antivirus Quarantine

Defender stores encrypted quarantine metadata and quarantined file contents under C:\ProgramData\Microsoft\Windows Defender\Quarantine\.

Quarantine contents typically preserve the quarantined payload alongside structured metadata, stored in Defender’s encrypted quarantine container format. This can allow for file recovery and deeper analysis even if the primary event logs have been cleared, though availability may depend on retention and cleanup policies.

Cross-correlation: Cross-correlate quarantine data with DetectionHistory to understand the user-facing narrative, and with Defender Operational event logs to confirm timing and remediation steps.

Microsoft Defender Support Logs

Defender generates plaintext troubleshooting logs (MPLog-*.log) and support archives under C:\ProgramData\Microsoft\Windows Defender\Support\.

These logs can carry surprisingly rich historical evidence of process execution, detected threats, scan results, and file existence. They commonly use UTC timestamps and can help identify process execution and file access during an incident.

Cross-correlation: Correlate MPLog observations with Defender Operational events and with DetectionHistory or quarantine evidence.

Wi-Fi Profile XMLs

Windows stores Wi-Fi profiles as XML files under C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces\{GUID}\.

These XMLs provide a reliable inventory of Wi-Fi networks configured on the device, frequently revealing SSIDs, authentication types, and encryption parameters. This is useful for supporting hypotheses about physical movement or corporate network access.

Cross-correlation: To determine when connections actually occurred, cross-correlate these profiles with Wi-Fi session evidence in the WLAN-AutoConfig event logs.

Wireless Network Report HTML

Generated manually via the command line netsh wlan show wlanreport, this HTML report summarizes Wi-Fi events for the past three days and is typically saved at C:\ProgramData\Microsoft\Windows\WlanReport\wlan-report-latest.html.

When present, it offers a human-readable timeline of connection sessions, disconnect reasons, and related adapter context. Analyze the wireless network report – Microsoft Support

Cross-correlation: Treat the report as a convenient aggregation and corroborate specific connect or disconnect timestamps with the underlying system logs it summarizes.

Local Group Policy cache (History)

To manage the removal of policies that no longer apply, Windows maintains a per-machine local Group Policy cache under C:\ProgramData\Microsoft\Group Policy\History.

This cache can help demonstrate that specific preference-based actions (like creating or deleting configuration objects) were applied to the endpoint, which is useful when domain-side evidence is missing.

Cross-correlation: Correlate this cache with Group Policy operational logs and Registry or application-state evidence to support conclusions about the lasting effects of the preference items.

StateRepository-Machine.srd

Located under C:\ProgramData\Microsoft\Windows\AppRepository\, this database records the state of installed modern applications.

This artefact supports software inventory tasks, revealing what Store or UWP packages were present. It logs apps currently installed, apps installed but never launched, and preinstalled apps.

Cross-correlation: To confirm exactly when an app was installed and who installed it, cross-correlate with Registry mappings of user IDs and relevant deployment event logs.

All-Users Start Menu Programs and Startup Folder

Windows maintains common Start Menu and Startup paths under C:\ProgramData\Microsoft\Windows\Start Menu\Programs and  C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup correspondingly.

The Startup folder is a frequent persistence location, executing its contents at user logon. Note that this is only one of many autorun and persistence surfaces; interpret findings as part of a broader autoruns review. Analyzing the LNK (shortcut) files found here allows investigators to:

• Detect malware persistence.
• Recover historical information, even for deleted targets or network shares.
• Use internal LNK timestamps and volume info to tie execution to specific devices.

Cross-correlation: Supplement shortcut analysis by correlating with Registry-based autoruns and file creation or auditing event logs.

OpenSSH Server Configuration

When enabled, the OpenSSH Server reads its configuration from C:\ProgramData\ssh\sshd_config.

The presence of this configuration file indicates OpenSSH Server may be installed and/or configured on the host, which can be relevant to remote-access and lateral-movement investigations. Confirm operational status by checking the sshd service state (installed/start type/running) and related configuration. The file reveals authentication settings and allowed users.

Cross-correlation: Correlate with service installation state, firewall rules, and authentication logs to build a complete access narrative.

Noisy and Low-Signal Artefacts

We filtered out certain C:\ProgramData artefacts from our primary analysis because they tend to be high-churn, diagnostic in nature, or too ambiguous without substantial auxiliary context. These are primarily relevant for general troubleshooting rather than reconstructing adversary or user behavior.

Update Session Orchestrator ETL Logs

Found under C:\ProgramData\USOShared\Logs\, these event trace logs are produced for Windows update orchestration diagnostics. They are too voluminous for targeted triage and mostly contain routine OS update activity.

DeviceMetadataCache

Located at C:\ProgramData\Microsoft\Windows\DeviceMetadataCache\, this directory caches OS device metadata packages. It is a benign maintenance cache with low forensic relevance.

Delivery Optimization Caches

These files assist with update distribution. They represent routine, noisy background updates and are weakly attributable to specific user actions.

Microsoft Defender Platform/Engine Folders

Found under C:\ProgramData\Microsoft\Windows Defender\Platform\, these directories contain frequent signature and engine updates. They are too volatile and weakly tied to discrete actions compared to other primary Defender artefacts.

Third-Party Application Data

While extensive third-party data exists in C:\ProgramData\, these artefacts are product-specific and not reliably generalizable across standard Windows systems, making them exceptionally noisy without knowing the exact software inventory.

Conclusion

As explored in this guide, the C:\ProgramData directory contains high-signal artefacts that provide a crucial, system-level perspective during an investigation. From uncovering background transfer intent and host-native security telemetry to reconstructing connection timelines, this path offers a reliable inventory of what happened on a specific endpoint.

However, even the best forensic tools won’t make investigative decisions for you. Parsers can organize data, but interpreting intent, building a clean timeline, and supporting attribution still takes an investigator applying informed judgment. To streamline collection and save time for analysis, consider using Elcomsoft Quick Triage to collect relevant artefacts from live systems, disk images, or mounted volumes.

We are grateful to the members of the forensic community whose research continues to drive the industry forward:

1. Windows Search database (artifacts.help)
2. Attacker Use Background Intelligent Transfer Service (BITS) (Google Cloud Blog)
3. Windows Error Reporting – Win32 apps (Microsoft Learn)
4. Uncovering Windows Defender Real-time Protection History with DHParser (SANS Alumni Blog)
5. Microsoft Defender Antivirus event IDs and error codes (Microsoft Learn)
6. Reverse, Reveal, Recover: Windows Defender Quarantine Forensics (NCC Group)
7. How to Use MPLogs for Forensic Investigations (CrowdStrike)
8. Analyze the wireless network report (Microsoft Support)
9. “All Installed Apps” Artifact – Windows 10 Forensics, (Boncaldo’s Forensics Blog)
10. Boot or Logon Autostart Execution: Registry Run Keys (MITRE ATT&CK)
11. The Missing LNK – Correlating User Search LNK files (Google Cloud Blog)