What to do after a password-sharing or access-facilitation accusation

Do not delete chats, revoke or alter accounts to conceal what happened, wipe devices, destroy password records, coordinate stories, or remotely erase logs. Preserve the entire conversation, not only the message containing the credential. Context before and after disclosure may show authorization, purpose, lack of knowledge, warning, revocation, or an intervening act.

Stop further use or distribution of the disputed access information unless current authorization and a legitimate need are clear. If ongoing access creates an immediate security risk, notify counsel and the appropriate owner or incident-response contact without accessing the system again.

Save the complaint, warrant, property receipt, release conditions, policies, contracts, work tickets, access approvals, role descriptions, system notices, training records, termination communications, and records identifying who owned or operated the security system.

Prepare a confidential chronology for counsel. Identify what information was disclosed, to whom, why, when, under whose authority, what the recipient said, what the accused understood, whether the information worked, what crime allegedly occurred, and what evidence connects the disclosure to it.

Do not assume an account owner’s claim resolves the case. The criminal statute requires proof of the accused’s mental state, the recipient’s intended and completed crime, and the link between facilitation and access.

The State must prove every part of section 609.8913

The accused must facilitate access to a computer security system. At the relevant time, the accused must know or have reason to know that the facilitation is aiding another person. That other person must intend to commit a crime. The other person must in fact commit a crime.

The statute is not phrased as strict liability for careless password handling. It does not punish every violation of a cybersecurity policy, every credential disclosure, or every instance in which a recipient later acts badly.

The charging document should identify the security system, confidential information or other means supplied, recipient, authorization, intended crime, completed crime, timing, and facts supporting knowledge or reason to know.

The underlying crime need not necessarily be a computer crime, because the statute says “a crime.” But the facilitation must provide access to a computer security system and aid the other person’s criminal objective.

Proof beyond a reasonable doubt applies to each factual element. Suspicion, hindsight, organizational policy, and civil negligence standards cannot reduce that burden.

What counts as facilitating access?

The statute says facilitation “includes” intentional disclosure of specified confidential information. “Includes” signals that the list is not necessarily exhaustive, but any unlisted theory should still involve enabling or easing access to the protected security system.

Listed examples are a computer password, identifying code, personal information number, or other confidential information about a security system that gives a person the means or opportunity to commit a crime.

Other alleged conduct might include supplying an authentication token, recovery code, API key, private key, session cookie, remote-access link, security answer, administrator credential, device certificate, bypass instruction, or confidential configuration. The State must prove what was supplied and how it enabled access.

Intentional disclosure matters for the listed examples. A phishing victim, accidental screen share, misaddressed message, exposed sticky note, compromised password manager, or unauthorized observation is not the same as deliberately giving the information to another person.

Facilitation should be distinguished from mere knowledge. Knowing another person’s password, seeing an access code, or understanding a system does not itself prove that the accused supplied a means or opportunity.

The information must concern a computer security system

Minn. Stat. § 609.87, subd. 11 (2026) defines a computer security system as a software program or computer device intended to protect the confidentiality and secrecy of data and information stored in or accessible through a computer system.

The State should identify the protective program or device. A login service, access-control application, multifactor token, firewall, encrypted vault, identity provider, lockout system, or physical authentication device may qualify. A general website or ordinary document may not.

The security system’s intended protective function matters. The definition focuses on confidentiality and secrecy. A tool concerned only with performance, convenience, or public content may not fit without evidence of its security purpose.

The confidential information must provide a means or opportunity for crime. A public username, obsolete code, revoked token, incorrect password, demonstration credential, or access detail unrelated to the attacked system may fail that connection.

Architecture can be important. Single sign-on, federated identity, shared administrator accounts, cloud tenants, service accounts, and role-based access may determine what a credential could reach and who controlled it.

Authorized sharing is not the same as criminal facilitation

Organizations routinely authorize credential-related work. Help desks issue reset links, managers delegate accounts, vendors receive API keys, administrators create service credentials, employees hand off on-call access, and families share certain services.

Authorization under section 609.87 generally rests on permission from the owner, operator, or designated representative and may be limited by time and purpose. Written policies, tickets, contracts, messages, prior practice, and supervisory instructions matter.

A policy against sharing can be evidence, but a policy violation alone does not establish every element of section 609.8913. The State must still prove the required knowledge and the recipient’s intended and completed crime.

Authority can be disputed. One manager may approve access while another later denies it. A vendor contract may allow support access but prohibit customer-data review. A current employee may have authority to create a temporary account but not to disclose a master credential.

Later misuse does not necessarily retroactively make an authorized disclosure criminal. The relevant inquiry is what the accused knew or had reason to know when facilitating access and whether the statutory facts existed.

“Knows or has reason to know” is a real mental-state requirement

Actual knowledge can be shown by admissions, direct messages, planning, warnings, prior requests, concealment, payment, or explicit discussion of the intended crime.

“Has reason to know” permits circumstantial proof, but it is not a license to convict solely because a risk seems obvious in hindsight. The State should identify facts available to the accused at the time that supported awareness of the criminal objective.

Warning signs may include a request to hide identity, use someone else’s account, bypass logging, access after termination, retrieve a specific victim’s data, defeat multifactor authentication, or avoid ordinary approval. Innocent explanations and industry practice still matter.

Carelessness and criminal awareness should not be collapsed. Reusing a password, sharing too broadly, failing to follow policy, or leaving a token exposed may be negligent cybersecurity. Section 609.8913 requires the knowledge formulation stated in the statute and aid to another’s crime.

The mental state must relate to both facilitation and the other person’s criminal intent. Knowing that access is unauthorized is not necessarily the same as knowing or having reason to know the recipient intends a crime.

The recipient must intend to commit a crime

The statute refers to “another” who intends to commit a crime. The prosecution should identify that person or provide proof sufficient to establish the other actor and intent even if the recipient is not jointly tried.

The accused’s own purpose and the recipient’s purpose may differ. A worker might share access for legitimate support while the recipient secretly intends theft. The recipient’s concealed intent is not automatically attributed to the person who disclosed the information.

Evidence of the recipient’s intent may include planning messages, target selection, tools, searches, transactions, threats, concealment, or the manner of access. The accused must be connected to the facts supporting knowledge or reason to know.

A vague plan to “look around,” prove a point, recover personal records, or test access may still lead to another offense, but the State must identify an actual criminal objective rather than assume all unauthorized use is the same crime.

If the accused and recipient are alleged to be the same person using two accounts, section 609.8913’s reference to aiding “another” deserves careful attention. The statute targets facilitation to someone else.

The other person must in fact commit a crime

This is one of the statute’s most important limits. An unused password, abandoned plan, failed attempt, or recipient who never commits a crime does not satisfy the text requiring that the other person “in fact commits a crime.”

The completed crime should be identified and proved. It might be unauthorized computer access, computer theft, computer damage, identity theft, fraud, stalking, extortion, invasion of privacy, or another offense, depending on the facts.

A company-policy violation, contract breach, terms-of-service violation, or civil tort is not automatically a crime. The prosecution must establish a criminal statute and its elements.

The recipient need not necessarily have a prior conviction before the facilitator can be charged, but the State must prove in the facilitator’s case that the crime occurred. A dismissed or uncharged recipient case does not mechanically resolve that proof either way.

If the underlying offense permits attempt liability, the wording “in fact commits a crime” may require analysis of whether a criminal attempt itself was completed as an offense. The charge should state the theory clearly rather than alternate between planned and completed conduct.

The facilitation must actually aid the other person’s crime

The statute says the accused aids another “by facilitating access.” That language requires a connection between the help and the criminal act.

If the recipient already had independent access, never used the disclosed information, entered through an unrelated exploit, or committed a different crime without the security system, the State’s causal theory may fail.

Logs can show whether the supplied credential, token, device, IP address, session, or recovery method was used. A password match alone may be inconclusive if credentials were shared or reused widely.

The information need not be the sole cause. It may be enough that it materially supplied the means or opportunity described by the statute. But temporal sequence alone—disclosure followed by crime—does not establish use or aid without supporting evidence.

Intervening acts matter. A recipient may alter the credential, phish another user, exploit a vulnerability, or obtain broader access from someone else. The forensic timeline should separate each event.

Employees, former workers, vendors, and contractors

Workplaces often use shared service accounts, team passwords, break-glass credentials, delegated mailboxes, temporary vendor accounts, and rotating on-call access. These practices may be poor security while still being authorized.

A departing employee who gives a successor the credentials requested by management presents different facts from one who secretly supplies a former coworker access for theft or sabotage.

Offboarding records can be decisive: notice time, access revocation, ticket ownership, credential rotation, remote-session termination, device return, vendor obligations, and instructions about business continuity.

A vendor may receive customer access for installation, maintenance, migration, testing, or incident response. Contracts, statements of work, data-processing addenda, security rules, and project communications define the permitted purpose.

Internal investigations sometimes identify every person who knew a team password as responsible. The criminal case must prove which person disclosed or otherwise facilitated access, what that person knew, and how the recipient used the help.

Family accounts, partners, roommates, and shared devices

Families and partners often share streaming, financial, home-security, phone, email, and device credentials. Ownership and permission can be informal, change over time, or depend on household roles.

Sharing an account for an ordinary household purpose is not automatically facilitation of crime. The State must prove the statutory security system, aid, mental state, recipient’s criminal intent, and completed crime.

Domestic disputes create difficult attribution questions. A credential may have been saved on a shared browser, synchronized through a family password manager, or known for years. Later revocation should be documented precisely.

A protective order, separation agreement, account notice, password change, device return demand, or express instruction can clarify authorization. Yet proof that a recipient knew access was unwanted is not necessarily proof that the disclosing person knew the recipient intended a crime.

Victim safety comes first. A person who discovers stalking, financial abuse, intimate-image access, or home-security compromise should preserve evidence and seek appropriate legal and safety assistance rather than confronting the suspected user.

IT support, security testing, and vulnerability disclosure

Security professionals necessarily handle sensitive access information. Authorized password resets, incident-response credentials, penetration tests, red-team exercises, vulnerability reports, and vendor escalations are not criminal merely because they can enable access.

Written scope matters: target systems, accounts, dates, testing methods, prohibited actions, data handling, subcontractors, and escalation contacts. Work outside scope may create risk, but a scope dispute does not itself prove knowledge of another person’s criminal purpose.

Publishing a vulnerability is analytically different from intentionally disclosing confidential information about a particular security system that provides another person the means or opportunity to commit a crime. Public research, confidential configuration, exploit code, credentials, and customer data should not be treated as identical.

A support technician may give a reset link to someone impersonating a customer. The technician’s diligence, authentication process, deception, training, and available warning signs matter to “knows or has reason to know.”

Responsible disclosure records can show an effort to notify the owner and prevent harm. They should be preserved with the full technical exchange and authorization history.

Evidence in a facilitating-access prosecution

Common evidence includes messages containing credentials, password-manager sharing records, reset emails, ticket history, identity-provider logs, multifactor events, access logs, IP records, device artifacts, camera video, payment records, and testimony from the recipient.

The State must authenticate the disclosure and its sender. Screenshots can omit account identifiers, timestamps, edits, surrounding conversation, forwarding history, and metadata. Native exports and device examination are often stronger.

Logs should show which credential or method was used. A successful login after disclosure is important, but the account may have had other valid tokens, active sessions, recovery methods, or users.

The recipient’s testimony may come with incentives: a plea agreement, reduced charge, employment protection, financial dispute, personal conflict, or effort to shift blame. Corroboration and prior inconsistent statements matter.

Knowledge is usually circumstantial. The defense should construct the set of circumstances proved and identify rational innocent explanations grounded in actual evidence rather than speculation.

Search warrants, provider records, and interviews

Investigators may seek phones, computers, password stores, cloud accounts, email, chats, access logs, financial records, and work systems. The warrant should establish probable cause and a nexus to each place or account and particularly describe what may be searched and seized.

A search for one credential-sharing incident should not automatically become unrestricted review of unrelated communications, privileged material, health data, family records, or other accounts. Date and subject limits matter.

Provider records can be incomplete. Retention periods, account time zones, shared IP addresses, deleted messages, token refresh, and export transformations should be documented.

Statements about passwords and users can be technically ambiguous. “I gave access” might mean adding an authorized role, sending a public link, lending a device already logged in, or disclosing a secret. Investigators should not supply the legal conclusion.

Custody, interrogation, Miranda warnings, voluntariness, promises, threats, translation, and recording completeness should be reviewed. A person should not consent casually to a broad device search or guess at technical details.

How section 609.8913 differs from related crimes

Unauthorized computer access punishes intentional unauthorized penetration or attempted penetration of a security system or electronic terminal. The facilitator may never personally log in.

Computer damage concerns intentional damage, destruction, alteration, or destructive-program distribution. Computer or electronic-data theft concerns specified taking, transfer, use, retention, concealment, or disposal.

Criminal use of encryption applies when encryption is intentionally used or attempted to commit, further, facilitate, or conceal crime, protect an offender’s identity, or disrupt another person’s computer operation under the statute.

General accomplice liability under Minn. Stat. § 609.05 uses different language and can carry liability for the underlying crime. Section 609.8913 is its own gross-misdemeanor offense with the specific access-facilitation elements.

Identity theft, financial-card fraud, invasion of privacy, stalking, extortion, and trade-secret theft may also be alleged. Each count requires separate proof and raises potential included-offense or duplicative-punishment questions.

Gross-misdemeanor punishment and practical consequences

The offense is a gross misdemeanor. Under Minn. Stat. § 609.03(2) (2026), the maximum is 364 days in jail, a $3,000 fine, or both.

Gross misdemeanors are not sentenced on the felony Sentencing Guidelines grid. Actual disposition depends on the charge, facts, criminal record, victim impact, negotiation, restitution, and sentencing considerations.

Conditions may restrict access to accounts, devices, networks, employers, victims, or confidential information. They can require return or deletion of data, monitoring, restitution, or compliance with civil protective orders, subject to legal limits.

The other person’s underlying crime may be a felony, and prosecutors may add accomplice, conspiracy, theft, fraud, or computer counts. Section 609.8913’s classification does not cap punishment for separately proved offenses.

Collateral consequences can include employment termination, professional discipline, school sanctions, security-clearance problems, immigration consequences, forfeiture exposure, civil claims, and reputational harm.

Reporting suspected computer crimes

Minn. Stat. § 609.8911 (2026) directs a person who has reason to believe sections 609.88, 609.89, or 609.891 are being or have been violated to report the suspected violation to the prosecuting authority in a county where all or part occurred.

The section provides criminal and civil immunity that otherwise might result from a good-faith report. It does not authorize destroying evidence, accessing additional accounts without permission, publishing private information, or making a knowingly false report.

A responsible report should preserve original records, distinguish observed facts from inference, identify urgent safety concerns, and avoid changing the system beyond authorized containment.

Organizations may also have contractual, insurance, professional, regulatory, breach-notification, or law-enforcement obligations. Those duties are fact-specific and should be coordinated with counsel and incident response.

A report made after learning that a disclosed credential was misused may support lack of criminal intent, but it is not automatic immunity from the facilitation charge. Timing, good faith, completeness, and earlier knowledge remain relevant.

Defense issues under section 609.8913

No facilitation occurred. The accused did not disclose, transfer, configure, or otherwise provide a means or opportunity for access; the recipient already possessed independent access.

The disclosure was not intentional. Phishing, accidental transmission, observation, malware, compromised password storage, or an unintended screen share may explain the information leak.

The access was authorized. Owner permission, delegation, work duties, a ticket, contract, household arrangement, or support role may show legitimate sharing.

The accused lacked knowledge or reason to know. The recipient concealed the criminal objective, gave a credible legitimate explanation, or acted outside the expected purpose without warning signs available to the accused.

No recipient crime was completed. The plan was abandoned, access failed, conduct amounted only to a policy or contract breach, or the State cannot prove the underlying crime.

The supplied information did not aid the crime. It was wrong, expired, revoked, unrelated, unused, or superseded by an independent method.

The system or information does not fit the statute. The alleged item may not be confidential information about a security system intended to protect data confidentiality and secrecy.

The evidence is unreliable or unlawfully obtained. Edited screenshots, missing context, poor attribution, incentivized testimony, overbroad warrants, invalid consent, or involuntary statements may support exclusion or reasonable doubt.

Minnesota authority and limits on reported decisions

No reported Minnesota Supreme Court or precedential Court of Appeals decision located for this guide comprehensively construes section 609.8913’s phrases “facilitating access,” “has reason to know,” “aiding another,” or “in fact commits a crime.” The statute was enacted in 2006 and its exact text should be the starting point.

Knowledge and participation are often circumstantial. In State v. Al-Naseer, 788 N.W.2d 469, 474 (Minn. 2010), the Minnesota Supreme Court said a circumstantial-evidence conviction “warrants heightened scrutiny.” The case did not involve computer credentials.

State v. Andersen, 784 N.W.2d 320, 329–30 (Minn. 2010), explains that the circumstances proved must exclude rational hypotheses inconsistent with guilt. The alternative must be rational and supported by the circumstances, not merely imagined.

State v. Colvin, 645 N.W.2d 449, 452 (Minn. 2002), states that penal statutes are “strictly construed.” Colvin was not a computer case; it supplies a general construction principle rather than a section 609.8913 holding.

Frequently asked questions about facilitating computer access