# Account controls in US insider threat guidance US insider threat guidance asks that account use trace to one person, shared accounts exist only when needed, access fit the job, and accounts close at exit. Updated: October 16, 2026 US guidance on insider threats asks for a short list of account controls. The Common Sense Guide to Mitigating Insider Threats, from the CERT National Insider Threat Center at Carnegie Mellon's Software Engineering Institute (SEI), covers them practice by practice. It asks that every account trace to one person, and that shared accounts exist only when necessary. People should keep only the access their current job needs, and every account should close when someone leaves. The Cybersecurity and Infrastructure Security Agency (CISA) adds that a departure plan should end both physical and digital access. ## Who counts as an insider CISA defines an insider as anyone who "has or had" authorized access to or knowledge of an organization's resources, such as its information, networks and systems. CERT's seventh edition defines insider threat in similar terms, and includes harm done by mistake as well as on purpose. CISA's fact sheet for HR teams names current and former employees, business partners and contractors. The "had" matters for accounts. A former employee who still knows a working password is an insider by both definitions. The CERT guide's seventh edition, published in 2022, is organized as 22 numbered practices. Four of them bear most directly on accounts: password and account management (10), privileged users (11), separation of duties and least privilege (15), and termination (20). Like the rest of the guide, these are recommendations, not law. ## Every account traces to one person Best Practice 10 lists the ways insiders get into accounts that aren't theirs. The first is passwords obtained through social engineering or because people shared them openly. CERT says account management should make access to critical systems traceable to individual people. On shared accounts, CERT says to use them "only when absolutely necessary." It notes that organizations often keep them for convenience rather than need. A shared account hides which person acted, which matters in investigations. Where one has to stay, CERT suggests a shared account password management tool. Its quick wins include making sure every shared account is necessary and covered by a risk decision. For contractors and vendors, the guide goes further. Every account must be attributable to one person, and contractors should not get shared accounts. When a contractor's staff member leaves, CERT says the contractor must tell you in advance, so you can change passwords or close the account. If advance notice isn't possible, the contract should require it within a reasonable time. Contractor and vendor accounts belong in your regular password changes. ## Only the access the current job needs Best Practice 15 pairs separation of duties with least privilege: people get only what their job requires. It warns that people who change jobs often keep their old access while gaining new access. Unless they still do the old work, CERT says to turn that access off. Its quick wins are to audit a person's permissions when they change roles, audit everyone's permissions at least once a year, and remove what's no longer needed. More on the idea is in [What is the principle of least privilege?](/guides/access-basics/what-is-least-privilege). For admins, the same practice says to require two accounts: one with only the admin rights the job needs, and a standard one for everyday work. Best Practice 11 explains why. Privileged users can usually hide what they did, by signing in as other users or editing logs. ## When someone leaves Best Practice 20 asks for a termination procedure with a checklist. For each task, the checklist names who does it, who checks it, and when it's due. The listed tasks include ending all accounts, cloud services among them. For departing privileged users, they include changing every shared account password. CERT explains why the password change matters with cases from its incident collection. In one, a contractor let go for poor performance used a shared account whose password hadn't been changed. He got into 24 user accounts after he left. CERT says many other cases follow the same pattern. Its advice is to keep a record of every shared account, and to change the password on each one a departing person could use. CISA's fact sheet for HR teams says the same in fewer words: have a plan to end the departing person's "physical and digital access." ## Finding accounts that shouldn't exist Best Practice 10 recommends periodic account audits to find four kinds of suspicious account. These are backdoor accounts, shared accounts, accounts made for outside parties, and accounts that are rarely used. It also asks for controls that let auditors trace all activity on the remaining accounts to one person. On monitoring, CISA's fact sheet for HR teams suggests a baseline of normal behavior, for both people and IT networks, so significant changes stand out. CISA's Insider Threats 101 fact sheet says successful programs use "practices and systems that limit or monitor access." ## Questions to check against your own setup - For each shared login, is there a written reason it can't be split, and a list of who may use it? - Do any vendors or contractors work under a shared login? - When someone changes jobs, does anyone check their old access? - Does the exit checklist name each cloud app and each shared password, with an owner and a due date? - For each app, can its log tell you which person used an account? ## Frequently asked questions **Is the CERT guide a legal requirement?** No. It's guidance from Carnegie Mellon's Software Engineering Institute, based on its analysis of 3,000 insider cases. The guide says its views aren't an official government position. **Does the guidance ban shared accounts?** Not for employees. CERT says to use them only when absolutely necessary and to make that a risk decision. For contractors and vendors, it says they should not get shared accounts at all. **Do former employees count as insiders?** Yes. CISA defines an insider as someone who has or had authorized access, and CERT's definition of insider threat uses the same words. A former employee who still knows a working password fits. **How often should we review who has access?** CERT suggests auditing a person's permissions whenever they change roles, and auditing everyone's permissions at least once a year, removing what they no longer need. ## Sources - [SEI CERT National Insider Threat Center, Common Sense Guide to Mitigating Insider Threats, Seventh Edition (2022)](https://www.sei.cmu.edu/documents/619/2022_019_001_886876.pdf) - [CISA: Insider Threat Mitigation](https://www.cisa.gov/topics/physical-security/insider-threat-mitigation) - [CISA: Human Resources' Role in Preventing Insider Threats (fact sheet, July 2024)](https://www.cisa.gov/sites/default/files/2024-07/hrs-role-in-preventing-insider-threats-fact-sheet_07-29-2024_508.pdf) - [CISA: Insider Threats 101, What You Need to Know (fact sheet, July 2024)](https://www.cisa.gov/sites/default/files/2024-07/insider-threat-101-fact-sheet_07-29-2024_508.pdf) ## How Junify handles this **Doing this by hand** You map each requirement to how your team actually works. You keep a record an auditor can review: which accounts exist, who may use each one, and who used it. And you reread the rules each time they change. **With Junify** Where a shared login can't be split, the guidance leaves you changing the password whenever someone leaves, and the app's log still can't name who did what. With Junify, the password is changed once and held by Junify. Each person verifies on their own phone before Junify fills in the login, so each use is tied to one person. When someone leaves, the admin removes their access in Junify. Junify is an access management service for handing work in your web accounts to employees, contractors and outside teams without giving them the password. Each person verifies on their own phone and clicks a card to sign in. The password is never shown, and Junify records who used which account and when. - [Try the demo](https://www.junify.com/bpo/try?lang=en&from=guide&cluster=compliance&slug=insider-threat-guidance-account-controls) - [Book a 30-minute demo](https://www.junify.com/bpo/demo) ## More on this topic - [What access logs need to show when you decide whether to report a breach](/guides/compliance/breach-notification-access-logs): Logs show whether data was viewed, by whom, for how many people and since when. HIPAA presumes a breach unless you can show a low probability of compromise. - [Password sharing and the federal anti-hacking law (CFAA)](/guides/compliance/cfaa-password-sharing): The CFAA turns on whether the system's owner allowed the access. In Nosal, former employees using a current employee's login acted without authorization. - [What CIS Controls 5 and 6 (v8.1) ask of your accounts](/guides/compliance/cis-controls-account-access-management): Control 5 asks for an account inventory, disabled dormant accounts and separate admin accounts. Control 6 covers granting and revoking access, and MFA.