OPSEC Guide: What a Military Discipline Actually Means for One Person

Why a military discipline applies to one person

OPSEC's origin is specific: US forces during the Vietnam War realized that adversaries were reconstructing operational plans not by breaking any single secret, but by combining scattered, individually unclassified observations — supply movements, radio traffic patterns, personnel schedules — into a complete picture nobody had explicitly leaked. The discipline that resulted doesn't protect one secret; it manages what an outside observer can piece together from everything visible at once. That reasoning transfers to an individual almost without translation: your address isn't secret, your employer isn't secret, your general daily schedule isn't secret, but an adversary who accumulates several of your individually unremarkable facts can reconstruct something you never intended to reveal — which market you use, where you live, or who you really are behind a pseudonym. The military origin isn't a strained metaphor; it's the same aggregation problem at a different scale.

The aggregation insight, concretely

No single fact about you is usually the risk. The risk is combination. A shipping city, a preferred vendor's specialty, an active hour of day, and a distinctive way of phrasing a support ticket are each unremarkable alone — a determined observer correlating all four against a handful of other data points can narrow "somewhere in this city, active at this hour" down to a specific, identifiable person, even without any single fact being a smoking gun. This is why OPSEC as a discipline focuses on the pattern across everything you reveal rather than treating each disclosure as an isolated decision — the individually safe choices are exactly where the real risk usually hides.

The process, applied to a private life

1. Identify critical information

For an individual, this isn't classified documents — it's whatever, if pieced together, connects a pseudonymous activity to your real identity or exposes you to real harm: your real name, address, employer, daily schedule, financial details, and the specific facts that link one online identity to another.

2. Analyze the threat

Who actually wants this information, and what could they do with it? A curious acquaintance, a data broker, a market operator, and a law enforcement agency are different threats with different capabilities and different odds of ever actually targeting you specifically — treating all of them identically wastes effort on the wrong ones.

3. Analyze vulnerabilities

Where does critical information actually leak? A reused username across contexts, a shipping address tied to a real name, a writing style distinctive enough to fingerprint across posts, metadata embedded in a photo — each is a specific, nameable leak point, not a vague sense of being "not careful enough."

4. Assess risk

For each vulnerability, how likely is exploitation, and how bad is the outcome if it happens? A low-likelihood, low-consequence vulnerability doesn't need the same response as a high-likelihood, high-consequence one — this step is what separates OPSEC from generic anxiety.

5. Apply countermeasures

Only now, once the first four steps have actually identified a specific, credible gap, do you pick a tool or habit to close it — never before.

Why "just use a VPN and Tor" is the wrong starting point

Countermeasures chosen before the process above is a guess dressed up as a plan — and a well-reasoned explainer of exactly this trap makes the case sharply: "the countermeasure-first approach of the 'best practices' fallacy has no place in opsec and ultimately leads to baseless paranoia."^opsec101.org The same source's own thought experiment is worth sitting with: if a deadbolt makes one door safer, why not put one on every door in the house, including the bathroom? Because past a certain point, more countermeasures cost real convenience for a threat that was never actually assessed as likely enough to justify the cost — "convenience is inversely proportional to safety and security," and a countermeasure applied without first identifying what it's actually defending against just as often creates a new vulnerability, or draws attention, as it closes one.^opsec101.org "Use a VPN and Tor" as a reflexive first move skips every step above — it's a countermeasure chosen before anyone asked what's actually being protected, from whom, or how likely the threat is, and it can leave the genuinely exploitable gaps (a reused username, a shipping address, a writing style) completely untouched while creating a false sense that "OPSEC" has been handled.

OPSEC versus privacy, security, and anonymity

Privacy

Controlling who can see what you do. A locked diary is a privacy measure.

Security

Preventing your data or systems from being read or altered without authorization. A strong password is a security measure.

Anonymity

Preventing an observer from knowing who is doing something, even if they can see that it's being done. A pseudonym is an anonymity measure.

OPSEC

The process that decides which of the above you actually need, against which threat, and how much of it — not a fourth tool alongside the other three, but the reasoning layer that tells you which combination of privacy, security, and anonymity measures a specific situation actually calls for.

What OPSEC means specifically for someone using Tor or a darknet market

Apply the same five steps to this exact context rather than a generic one. Critical information here specifically includes: any real-world identifier that could connect a market account to you (a shipping address, a payment trail, a writing style you also use under your real name), and any detail about your buying pattern that narrows down who you are among a smaller pool of possible people than the internet at large. Threats specifically include the market operator itself, a rival vendor, a phishing operator running a fake mirror, and — depending on jurisdiction and what's being purchased — law enforcement. Vulnerabilities specific to this context: paying with Bitcoin rather than Monero, reusing a username across a market and a clearnet account, verifying a market's address carelessly and landing on a clone, and discussing order details outside PGP encryption. This is the exact connection generic OPSEC guides don't make, because none of the pages currently ranking for this topic address Tor or darknet markets at all — every countermeasure this site recommends elsewhere, from PGP verification to using Monero, is downstream of applying this same five-step process to this specific set of threats.

Building your own threat model, not just a checklist of best practices

Everything above is the reasoning. This is where it turns into something you can actually hold — a personal threat model, in the specific sense security researchers use that phrase, and a different object from a checklist of best practices copied off a blog. A best-practices checklist tells everyone to do the same fixed list of things regardless of who they are; a threat model starts from the fact that a journalist, a Tor-curious reader, and a market buyer are protecting different things from different people at different costs, and produces a different answer for each of them. EFF's own security-planning module opens with exactly this distinction: "trying to protect all your data from everything all the time is impractical and exhausting," and the alternative it teaches is "thoughtful planning" built around a short list of questions rather than a universal list of actions.^EFF Their six questions map directly onto this page's five-step process: what do you want to protect (your critical information), who from (the threat), how bad if it fails and how likely (the risk), how much trouble you'll go through (the countermeasure), and — the one this site's five-step process leaves implicit — who your allies are, since "digital privacy and security is a team sport" whenever a threat you face is shared with a partner, a housemate, or a fellow buyer.^EFF

Software teams run a structured version of the same exercise, and OWASP's own definition of the practice reads, almost word for word, like the process above applied to code instead of a person: "threat modeling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value," through a four-question loop — what are we working on, what can go wrong, what are we going to do about it, did we do a good job.^OWASP That loop is sound, but it was written for an application with components and data flows, not a person with an address and a shipping habit, which is exactly the gap the OWASP and MDN pages leave for a reader who searches for personal threat modeling and finds software documentation instead. The "assets" here are not user records; they are your real name, your location, your income, your relationships, your physical safety, and your freedom — the things that, in combination, an adversary reconstructs into a picture of who you are and what you do, per the aggregation problem above.

Threat, vulnerability, and risk — told straight, not as jargon

These three words get used interchangeably in casual writing about security and mean specifically different things once you're building a model rather than talking in general terms. MDN's own worked example is the clearest version of this available anywhere, and it translates without modification: "Threat: a burglar. Vulnerability: an unlocked window or a weak door lock. Attack: the burglar climbing through the window or picking the lock. Mitigation: a strong deadbolt, an alarm system, a policy to ensure all windows are locked... Risk: we announced publicly that we are away on vacation, which increases the risk for burglars to try to get into our house."^MDN Translated to this site's readers: the threat is a market operator, a rival vendor, or a law enforcement agency; the vulnerability is a reused username, an unencrypted order detail, or a shipping address tied to a real name; the attack is the specific moment someone actually exploits that opening rather than merely being capable of it; and the risk is how likely that specific combination actually is for you, which is not the same question as whether the threat exists in the abstract. A threat that exists everywhere but is vanishingly unlikely to target you specifically carries a different risk than the same threat aimed at a person law enforcement has already flagged, even though the underlying threat and vulnerability look identical on paper.

Judging likelihood honestly, in both directions, is harder than it sounds. EFF's own guide makes the same point with a physical-world comparison worth keeping: "there is a threat that your building might collapse, but the risk of this happening is far greater in San Francisco... than in Stockholm."^EFF The threat is identical in both cities; only the risk differs, because risk is threat multiplied by the actual conditions you're in. Dismissing a real, likely threat because "it probably won't happen to me" and treating every conceivable threat as equally urgent are the same mistake in opposite directions — both skip the step where you actually weigh likelihood against a specific vulnerability, rather than reacting to how alarming the threat sounds.

Baseline, raised, and high-risk: what each tier actually costs

Once assets, adversaries, vulnerabilities, and risk are named rather than assumed, the digital security basics almost everyone should have separate cleanly from the countermeasures that only some readers need — and the daily-friction cost rises sharply between the three tiers below, which is the actual reason to stop at the tier your own risk assessment justifies rather than climbing straight to the top out of general anxiety.

Four worked threat model examples for this site's readers

Generic threat-modeling guides tend to use a stranger's blog or a corporate network as the worked example, which is exactly the gap left open for the four kinds of readers this site actually has. Working through each one shows how the same five-step process and the same three tiers produce genuinely different answers.

The Tor-curious reader

Asset: mostly just the fact that they use Tor at all, plus ordinary browsing habits they'd rather not have tied to their name. Adversary: an ISP, an employer, or a curious acquaintance rather than a targeted investigation. Top vulnerability: logging into a real-name account inside the same Tor session as anything else. Fit: baseline plus Tor Browser's own safety habits — raised-tier tools like a dedicated OS are overkill here.

The market buyer

Asset: identity, shipping address, and purchase history. Adversary: the market operator, a rival vendor, a phishing clone, and — depending on jurisdiction and what's being bought — law enforcement. Top vulnerability: paying with Bitcoin instead of Monero, or a shipping address that traces to a real name. Fit: raised tier as a floor — Monero, PGP-verified addresses, and a dedicated purchasing identity kept away from anything else.

The crypto holder

Asset: funds and the transaction history that a public ledger makes permanent. Adversary: blockchain analytics firms, exchanges under subpoena, and anyone who gains physical access to a device or a backup. Top vulnerability: leaving funds on an exchange, or a hardware wallet backup stored somewhere it can be found. Fit: raised tier for the coin choice and withdrawal habits, high-risk tier — multisig, a hardware wallet chosen per the hardware wallet guide — once the holdings justify the added friction.

The journalist or source

Asset: a source's safety, a story before publication, and their own physical safety in some contexts. Adversary: a named, resourced organization or state actively motivated to identify them, not a generic curious party. Top vulnerability: any single point where the digital and physical worlds touch — a phone carried into a sensitive meeting, a document with embedded metadata. Fit: high-risk tier as the floor, not the ceiling — a dedicated secure operating system chosen deliberately rather than by habit.

What you end up holding, and what residual risk you're accepting

The finished artefact from this exercise is small on purpose: a short list, written down or just held clearly in your head depending on your own threat model, naming your actual assets, your two or three realistic adversaries, the specific vulnerabilities that connect them to those assets, and which tier of countermeasure you've chosen for each one and why. Redo it — not from scratch, just a fresh pass through the same short list — on the same triggers named below, rather than treating this artefact as something you file away and never open again. It is not a security audit and it does not aim for completeness — MDN's own framing of the same exercise for software is true here too: "threat modeling is not about completeness; it's about improving understanding over time."^MDN A model that tried to cover every conceivable threat would be paranoia by another name, the same failure mode the deadbolt-on-every-door example above already names.

Every finished model leaves something deliberately unaddressed, and naming that residual risk explicitly is the point of the exercise rather than a gap in it. MDN's own framework for responding to a threat includes, alongside eliminating, reducing, and transferring it, the option to formally accept a threat as one "it is still open and needs to be monitored" rather than fixed^MDN — for most readers of this site, the accepted residual risk is a state-level adversary with essentially unlimited resources, which no personal-scale countermeasure closes, and a catastrophic but low-likelihood event nobody reasonably spends daily-friction budget defending against. Writing that acceptance down, even just mentally, is different from never having considered it at all.

Telling proportionate from paranoid

The test is whether a specific step above actually justifies a given countermeasure, not whether the countermeasure sounds serious. Proportionate: using Monero instead of Bitcoin for a market purchase, because the vulnerability (a permanent public transaction record) and the threat (blockchain analysis) are both real and specifically identified. Paranoid: refusing to ever use the same computer for anything else, changing your entire online identity weekly, or treating every acquaintance as a suspected informant with no specific reason to believe any of them are — countermeasures applied with no threat actually identified to justify their cost, which is precisely the failure mode opsec101's own deadbolt-on-every-door example illustrates.^opsec101.org If you can't name the specific threat and vulnerability a countermeasure addresses, it's very likely paranoia dressed up as caution rather than OPSEC.

What OPSEC cannot do

OPSEC is a reasoning process, not a magic shield, and it inherits the honest limits of every tool it might recommend. Tails' own documentation states this directly about the strongest tool in this space: "Tails is safer than any regular operating system. But Tails, or any software or operating system, cannot protect you from everything — even if they pretend to."^Tails OPSEC cannot protect against a hardware-level compromise — a physically altered device, a firmware-level attack — that exists below the level any software-based countermeasure can reach.^Tails It cannot protect against a mistake made once, in a moment of carelessness, that a perfect process the rest of the time doesn't undo. And it cannot protect against a sufficiently well-resourced, patient adversary who's specifically decided to target you rather than the general population — no personal-scale process closes that gap, and pretending otherwise is its own form of the paranoia this whole discipline exists to avoid.

If you have one hour, fix this first

Start with whatever single vulnerability would do the most damage if exploited, not the one that's easiest to fix. For most readers of this site, that's identity separation: check whether a username, writing style, or contact detail connects a pseudonymous account to anything identifiable, and break that link first — it's the single most common way real people get connected to pseudonymous activity, and it's usually a bigger gap than any specific tool choice. After that, in order of typical impact: enable a password manager and unique passwords if you're not already using them, verify you're not reusing addresses across contexts, and confirm your most-used market or communication channel is actually verified rather than assumed safe.

What should trigger doing this again

Revisit the process, not just the countermeasures, whenever your actual situation changes: a new relationship with access to your devices or accounts, a move to a new jurisdiction with different legal exposure, a market or service you use getting breached or shut down, a change in what you're buying or doing that changes the consequences of exposure, or simply enough time passing that your last assessment no longer reflects your current habits. OPSEC done once and never revisited quietly drifts out of date exactly as your actual risk changes — the process is a habit to repeat, not a checklist to complete once and file away.