BYOD for developers: should you allow personal laptops?

Allow personal laptops for developers only for work that does not touch your most sensitive code or data, and only with a short list of enforced minimums: disk encryption, current updates, a screen lock and separate accounts. For high risk work, issue a company laptop. The decision is about data, not about trust in people.

Start with what the guidance covers

NIST SP 800-46 Revision 2, published in July 2016, is titled the Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security. It applies to both organisation issued and personally owned devices, and says the components involved should be secured against expected threats identified through threat models. The page gives the scope and not the full list of recommendations, so read the publication itself before quoting it in a policy.

That framing is useful. Begin with a threat model, not with a device list.

Sort your work into tiers

1. Low risk. Documentation, public open source work, front end prototypes with no secrets. Personal devices are usually acceptable with baseline controls.
2. Medium risk. Internal source code, staging access. Personal devices are possible with enforced encryption, a managed browser profile or a remote development environment.
3. High risk. Production access, signing keys, customer data, regulated workloads. Use a company device. If that is not possible, use a remote desktop or cloud workspace where nothing lands on the personal disk.

Minimums to enforce on any personal laptop

• Disk encryption turned on. See the guides for FileVault and BitLocker.
• Operating system on a supported version with automatic updates.
• Screen lock and a strong login password.
• A separate user account or profile for work.
• Passphrase protected SSH keys, ideally hardware keys. See SSH key passphrases.
• Work credentials in a password manager, never in plain text files.

What you give up with BYOD

You cannot easily inspect the machine. You cannot control what else is installed. You cannot recover a personal device that is lost, and a wipe of a personal laptop is not something most people will accept. Your leaving process has to cope with company data on a device you do not own.

That last point shapes the design. If code and data stay in a managed cloud workspace, offboarding is revoking an account. If code is cloned to a personal laptop, offboarding depends on trust.

Questions to answer before you write the policy

• Which repositories and systems can be reached from a personal device?
• How do you verify a device meets the minimums? Self attestation is weak. Device checks at sign in are stronger.
• What happens to company data on departure?
• Who pays for a security incident on a device you do not control?
• Which regions or contract terms limit where data can live?

Employment and privacy law varies by country and by state, so involve legal counsel before you monitor or wipe anything on a personal device.

Mobile devices have their own options. See MDM vs MAM for BYOD.

Quick check

Sources

• NIST SP 800-46 Rev. 2, Guide to Enterprise Telework, Remote Access, and BYOD Security

Last reviewed: 19 October 2026.