Settings Sync is the feature that synchronises a user's editor settings, keybindings, extensions, and related preferences across devices. In VS Code practice it copies selected configuration data through an account-linked sync process, which can also move sensitive settings or secrets if they are stored in synced files.
How Settings Sync Works
Settings Sync is a convenience feature that keeps a user’s editor experience consistent across devices by replicating preferences, keybindings, extensions, and similar configuration state through an account-linked sync process. In practice, it reduces manual setup, speeds device changes, and makes the editor feel “the same” wherever the user signs in.
The core idea is not just copying preferences once, but maintaining a synchronised profile over time. That makes it useful for productivity, yet it also means the synced set becomes part of the user’s portable configuration state rather than something bound to one machine.
What Settings Sync Typically Carries
Settings Sync usually includes the material that shapes how the editor behaves, such as UI preferences, formatting choices, shortcuts, installed extensions, and sometimes workspace-related settings. The exact scope can vary by product and by what the user chooses to include, so the feature should be treated as a selective replication mechanism rather than a blind copy of everything on disk.
That distinction matters because configuration is not always harmless metadata. Editor settings can influence extension behavior, automation, trusted workflows, and other operational details that affect how code is edited, run, or exposed.
Where users store secrets, tokens, hostnames, or other sensitive values in synced configuration files, the sync boundary can also become a data-handling boundary. In those cases, a convenience feature starts to overlap with secret handling and access control.
Why Settings Sync Matters for Security
Settings Sync matters because it can move sensitive configuration across devices, accounts, and trust boundaries. If a synced profile contains secrets or privileged tooling preferences, compromise of the sync account or a synced endpoint can expose more than cosmetic settings.
The main security concern is not the feature itself, but what is placed into it. A misused sync channel can propagate risky extensions, insecure defaults, credential-like material, or an unwanted configuration drift to every device connected to the account.
For that reason, many of the same concerns apply here as in broader configuration and account governance, including least privilege, account protection, review of synced content, and attention to what data is actually being replicated.
How to Evaluate and Control Settings Sync
Start by understanding which settings categories are actually included and whether any of them contain credentials, API keys, certificates, tokens, or environment-specific values. If sensitive material appears in the sync set, it should be removed from the synced path rather than relied on as if it were a secret store.
Review the sync scope after major environment changes, because old preferences and extensions can reappear on new devices and recreate unwanted behavior. This is especially important when developers move between personal and managed devices, or when teams use shared editor baselines.
Protect the account behind the sync feature as a security boundary in its own right. If that account is compromised, the attacker may inherit the user’s editor configuration, extension footprint, and any sensitive values that were mistakenly included in the sync set.
Risk and Threat Considerations
Settings Sync can create a hidden exposure path when users store secrets, tokens, or environment-specific configuration in files that are meant to travel between devices. The risk is amplified when the sync account is reused across laptops, workstations, or personal devices, because one compromise can propagate to every synced endpoint.
Failure mechanism: Sensitive settings are synced as ordinary configuration, then copied into a device or account that is less trusted, more exposed, or easier to compromise. Attackers can then recover secrets from synced data, abuse synced extensions or preferences, or use the account link to persist configuration changes across devices.
Impact: Secret exposure, account takeover amplification, unwanted configuration drift, and broader compromise of developer or operator workflows can follow, especially when synced data includes tokens, connection details, or privileged tooling settings.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Settings Sync can carry secret-like material that must be managed like other credentials. |
| AC-6 — Least Privilege | Limiting synced configuration reduces the blast radius of exposed or over-shared settings. | |
| Recommendation — Exclude secrets from synced settings and manage any stored credentials under a formal credential lifecycle. Limit sync scope to the minimum settings needed for work and remove sensitive values from portable profiles. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Settings Sync depends on account-linked access decisions for who can retrieve synced configuration. |
| Recommendation — Control who can access synced configuration and restrict sync-enabled accounts to approved devices and users. | ||
| CIS Controls v8 | CIS-5 — Account Management | Sync features rely on managed accounts and the security of those accounts determines exposure. |
| Recommendation — Harden and monitor the account used for sync and remove access when it is no longer needed. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Synced settings can inadvertently move secrets, tokens, or keys across devices. |
| Recommendation — Keep secrets out of synced settings and scan configuration paths for leaked credentials before enabling sync. | ||
Practitioner Guidance
Why practitioners should care: Treat Settings Sync as a governed data pathway, not just a convenience feature. The practical question is whether the settings being replicated are safe to move across every signed-in device and whether any of them should be excluded because they carry security-sensitive material.
Common misunderstanding: Many teams assume “settings” are low risk, but editor preferences can contain operationally important or secret-bearing values. A synced profile should be reviewed with the same discipline applied to any other portable configuration store.
Practitioner takeaway: Keep secrets out of synced configuration, limit what is eligible for sync, and review the feature as part of account and endpoint security rather than as a purely usability setting.
Related resources from NHI Mgmt Group
- Why do browser sync settings matter for identity security?
- Who is accountable when consent records, preference settings, and privacy workflows fall out of sync?
- How should organisations validate that cloud sync settings are not exposing sensitive data to the public internet?
- What signs show that privacy settings and identity controls are out of sync?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org