Maintaining OPSEC Over Time: Rotation Schedules for Accounts, Keys, and Devices

Most OPSEC failures I’ve looked at weren’t dramatic. Nobody got burned because they misconfigured Tor. They got burned because an account they made in 2021 was still active in 2025, tied to the same recovery email, and it leaked one small fact that made the rest of the picture line up. Rotation is the unglamorous fix. It’s also the part almost everyone skips, because nothing happens right away when you skip it.

So this is about schedules. What to rotate, how often, and where rotation actually earns its keep versus where it’s just ritual. Research and defensive framing only: no market links, no access instructions.

Start with what an adversary can aggregate

OPSEC is usually defined around controlling small, seemingly insignificant data points that, combined, reveal the critical picture. Splunk’s write-up on building an OPSEC program puts identity and role data near the top of the list of things those controls exist to protect. That matters for rotation planning, because a single indicator is rarely the problem. The problem is a set that connects.

A username reused across three services is a set of one problem. A PGP key that signed messages under two identities is the same problem wearing a hat. Fortinet’s summary of OPSEC theory leads with a blunt question: if you don’t know the threat, how do you know what to protect? Answer that before you build a rotation calendar, or you’ll be rotating things nobody was looking at.

The rotation schedule I’d actually recommend

These aren’t laws. They’re defaults you adjust to your threat model. I’ll flag where I think the common advice is wrong.

Accounts

• Anything tied to a real-world footprint: rotate or retire on a fixed 90-day review. “Review” means decide to keep, rebuild, or delete. Not just change the password.
• Pseudonymous accounts with an active role: full identity rotation (new persona, new infrastructure, new writing habits) every 6 to 12 months, or immediately after any contact with someone who got compromised.
• Dormant accounts: delete, don’t park. The OPSEC privacy handbook is direct about this: minimising attack surface includes deleting accounts and data you no longer need, and EU residents can push a GDPR erasure request. An account you forgot about is not neutral. It’s a stale copy of your old behaviour sitting somewhere you don’t control.

The retirement step is the one people skip. Rotating a password on an account you should have deleted keeps the exposure alive and just makes you feel productive.

Keys

Long-lived credentials are the single most over-discussed and under-rotated category in security writing. After the 2026 cloud intrusions, the defensive consensus hardened into something close to a rule: assume credential exposure, and aggressively rotate secrets, keys, and tokens across every layer. The related analysis from the same reporting is even sharper, arguing that eliminating long-lived IAM credentials is now baseline, not optional.

You can translate that straight into personal practice:

• SSH keys: set a calendar expiry of 12 months, and treat “who has the public half” as a document you maintain. The Accenture breach write-up is instructive here: when a 35 GB credential dump surfaces, the affected organisation has to systematically audit and rotate SSH keys, storage access keys, and API tokens across every environment where they’re valid. If you can’t list where a key authenticates, you can’t rotate it safely. That’s a documentation problem more than a crypto problem.
• PGP keys: rotate on suspected compromise, and also on a schedule if the key has ever signed something under a different pseudonym. The signature linkage is the leak, not the key material.
• API tokens and app passwords: shortest possible lifespan. Revoke on any device change, not on a calendar.
• Wallet seeds and recovery phrases: treat as non-rotatable by design, which flips the whole model. If a recovery phrase may have been typed into a compromised device, the only remediation reported in the macOS stealer cases is to move the assets to a new recovery phrase from a trusted device. That’s a rotation you do once, correctly, and it’s the reason seed hygiene outranks every password rule on this page.

Devices

Devices are where rotation is most often a rebuild, not a reset. When compromise is confirmed, the safer response pattern in appliance breach guidance is to factory-reset, rebuild with patched firmware, and restore only a known-good pre-exposure configuration, then rotate admin, directory, and user credentials the device handled. Ransomware groups go after edge devices for a reason: one appliance is a fast route inward.

For a personal device I’d propose a 12 to 24 month “rebuild window” as a target, not a schedule you beat yourself up over. The rebuild matters more than the interval. Non-production environments should be rebuilt from trusted templates rather than manually cleaned, per the same guidance, and that reasoning applies to your throwaway VMs too. A golden image you rebuild from beats a machine you’ve been scrubbing for two years.

Detection: the part that makes rotation timely

Rotation on a fixed schedule is only half the loop. The other half is knowing when to accelerate it, and that means watching for the boring signals. Odessey stealer coverage highlights exactly the indicators a Mac-based researcher should watch: unfamiliar LaunchDaemons, unusual outbound connections, and unexpected changes to wallet applications.

The response pattern is worth memorising because it inverts normal muscle memory. Disconnect from the network. Change credentials from a separate trusted device. Review financial and crypto accounts. Then get incident support before restoring normal access. If you rotate from the suspected box, you hand the attacker your new credentials for free.

Automation is the other lever. Post-incident analysis consistently lands on the same point: detection, credential rotation, and containment should be automated to match attacker speed, because manual rotation across a dozen services doesn’t happen under stress. At a personal scale that means scripts or a checklist that runs, not a mental note.

Where this advice gets annoying, and my honest take

A 90-day cadence on everything is friction theatre. People who rotate hard on a fixed schedule across all accounts end up with a password manager nobody audits, key pairs nobody documents, and a spreadsheet of accounts they’ve stopped maintaining. I’ve seen it, and the schedule becomes the threat model.

My actual position: rotate rarely but documented. If you can’t state where a key authenticates and who holds the public half, fix that before you touch the calendar. Credential inventory is the precondition for rotation, not a nice-to-have. Identity-first controls, MFA, session revocation, and disabling compromised accounts immediately all assume you know which accounts exist, which is exactly the data an OPSEC program is supposed to protect in the first place.

One more thing the sources won’t tell you, because it’s my observation: the biggest rotation leak isn’t keys. It’s behaviour. A new persona that writes in the same sentence rhythm, logs in at the same hours, and reaches for the same tools is not rotated, no matter how many times you changed the password. Account and key rotation is measurable. Style rotation isn’t, and it’s the part that gets people.

Treat these schedules as a starting point you’ll tune against your own threat model. The threat is the input. Everything else is bookkeeping.