# What NIST SP 800-46 says about telework and personal devices

NIST SP 800-46 Rev. 2 says to assume outside devices and networks are hostile, decide which devices may reach which systems, and prefer multi-factor sign-in.

Updated: October 16, 2026

NIST SP 800-46 Rev. 2 is NIST's guide to securing telework, remote access and personal devices (bring your own device, BYOD). It tells you to assume that devices and networks outside the office are hostile. Each organization decides which kinds of device may reach which systems, giving the least-controlled devices the least access. For organizations with higher security needs, it suggests sign-in that doesn't rely on passwords alone. It doesn't ban personal devices.

## What the guide covers

NIST published Rev. 2 in July 2016. It covers the devices people use, the remote access servers they connect to, and the internal systems they reach. It also covers the policy that ties them together. It's written for federal agencies, and NIST says nongovernmental organizations may use it voluntarily.

## Start by assuming the outside is hostile

The guide's first recommendation is to plan as if the places, networks and devices outside your control are hostile. It spells out three assumptions:

- Telework devices will be lost or stolen, and whoever gets one will try to pull data from it or use it to get in.
- Networks outside the office can't be trusted, so traffic may be read or changed.
- Devices will get malware.

For a lost or stolen device, the options it gives are encrypting the device's storage, encrypting sensitive data on it, or not storing sensitive data there at all. To stop someone from using a lost device to get in, the main option is strong authentication, "preferably multi-factor."

## Four kinds of device

The guide sorts devices by who is responsible for securing them:

- Organization: bought, configured and managed by the company.
- Third-party-controlled: managed by a contractor, partner or vendor, under a contract with you.
- BYOD: owned by the worker, who is fully responsible for securing it.
- Unknown: devices nobody vouches for, such as a hotel kiosk or a relative's laptop. The guide calls their use extremely risky.

The trouble with devices you don't control is enforcement. The guide notes that even with agreements in place, those agreements "generally cannot be automatically enforced." So an infected or poorly secured device may end up connected to your systems. Telling users their duties improves security on personal devices, it says, but doesn't match controls you enforce on your own devices.

## Four ways to reach company systems

The guide groups remote access into four methods, which differ in where software and data end up.

| Method | What it is | Where work data ends up |
| --- | --- | --- |
| Tunneling | A virtual private network (VPN) links the device to the company network | On the device, with the apps |
| Portals | A server runs the apps, and the device sees screens or web pages | Mostly on the server; on the device only briefly, unless downloads are allowed |
| Remote desktop | The device controls the person's own office computer | On the office computer, though files can be copied over |
| Direct application access | The device reaches one app directly, such as webmail in a browser | On the device, if the app lets people download files |

Most of these methods can let people store data on their device, and data can also land there by accident, for example in the browser's cache. The guide asks that data sent to remote workers follow your data retention rules.

Direct application access is the method that fits a cloud app opened in a browser. The guide says the app itself provides the security in that case: encryption, sign-in and so on. It sees this as generally acceptable only for systems on the network's edge or in a public cloud, not for internal ones.

## Give the least-controlled devices the least access

The guide says a telework security policy should spell out which forms of remote access you allow and which types of device may use each one. It should also say what access each kind of worker gets and how accounts are set up. Its example tiers access by device. Company computers reach many resources. Personal and contractor computers reach a limited set. Personal phones and tablets reach just one or two low-risk resources, webmail for example.

The factors it lists include how sensitive the work is, how confident you can be that a device follows your rules, cost, and where people work from. For high-risk work, it suggests allowing only company devices with multi-factor sign-in and encrypted storage.

## Signing in from a device you don't control

On authentication, the guide makes three points. If passwords are the only check, the remote access password should generally differ from the company's other passwords. It makes an exception for direct application access, and says to assume some people will reuse passwords anyway. Where security needs are higher, consider sign-in that doesn't rely on passwords alone. It also notes that many organizations make people sign in again during long sessions, such as after 8 hours or after 30 minutes idle.

The guide also covers checks on the device itself before access is granted, such as up-to-date patches and antimalware. It warns that malware can easily get around many of these checks. It suggests mobile device management, and app management that keeps work apps and data in a separate space that can be wiped when someone leaves.

## What that leaves to account controls

With direct application access, nothing sits between the personal device and the app except the app's own sign-in. So for cloud apps used from personal devices, the account controls carry the weight. That means who has a login, how strong the sign-in is, whether the password stays on the device, and how fast access ends when someone leaves. How the device-side options compare is covered in [Options for letting staff use personal devices for work systems](/guides/access-basics/byod-options-mdm-vdi-browser). What a personal computer keeps afterward is in [What work data stays on a personal computer, and how to keep it off](/guides/access-basics/byod-leave-no-business-data).


## Frequently asked questions

**Does NIST SP 800-46 allow personal devices?**

Yes. It leaves the decision to each organization, based on risk. In its example, personal phones and tablets get just one or two low-risk resources, webmail for example.

**Is there a newer version than Rev. 2?**

NIST issued a pre-draft call for comments on a Rev. 3 on September 10, 2020, and comments closed October 30, 2020. Rev. 2 from July 2016 is still the final version.

**Does it require multi-factor authentication?**

It says organizations with higher security needs should consider sign-in that doesn't rely on passwords alone. It notes that federal agencies must use two-factor sign-in for remote access under OMB Memorandum M-07-16.

**Does SP 800-46 apply to private companies?**

It's written for federal agencies. NIST says nongovernmental organizations may use it on a voluntary basis.

## Sources

- [NIST SP 800-46 Rev. 2, Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security (July 2016)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-46r2.pdf)
- [NIST CSRC: SP 800-46 Rev. 2 publication page](https://csrc.nist.gov/pubs/sp/800/46/r2/final)
- [NIST CSRC: SP 800-46 Rev. 3, Pre-Draft Call for Comments, Guide to Enterprise Telework Security (September 10, 2020)](https://csrc.nist.gov/pubs/sp/800/46/r3/iprd)

## 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** For web apps reached straight from a personal computer, the app's own sign-in is the control. With Junify, only the browser extension goes on that computer. Each person verifies on their own phone, Junify fills in the login without showing the password, and the account opens in an incognito window, so closing it leaves no saved password or browsing history. Each use is recorded by person.

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=nist-800-46-telework-byod)
- [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.