Usar el mismo usuario con permisos de administrador para todo es uno de los errores de seguridad más habituales en Windows, tanto en casa como en entornos profesionales. Separar la cuenta diaria de trabajo de las cuentas con privilegios elevados y conocer bien las cuentas internas del sistema es clave para reducir riesgos, proteger la privacidad y frenar el malware.
A lo largo de este artículo vas a ver, paso a paso, cómo crear y gestionar cuentas locales seguras para el uso diario, qué tipos de cuentas existen en Windows (incluidas las ocultas del sistema), cómo configurarlas en Windows 10 y Windows 11, qué ha cambiado en versiones recientes y qué políticas y buenas prácticas deberías aplicar si administras varios equipos o un aula completa.
Qué es exactamente una cuenta local en Windows y por qué conviene usarla
En Windows puedes iniciar sesión con una cuenta de Microsoft o con una cuenta local. La cuenta de Microsoft está vinculada a un correo (Outlook, Hotmail, Live, etc.) y se integra con OneDrive, Microsoft Store, sincronización de ajustes, Xbox, Office y otros servicios en la nube. Todo eso está muy bien, pero implica más exposición de datos y dependencia de la identidad online.
La cuenta local, en cambio, es una cuenta que solo existe en ese equipo. El usuario tiene su carpeta de perfil, documentos, imágenes, escritorio, etc., pero no se sincronizan configuraciones ni archivos con la nube de Microsoft. Este enfoque ofrece un mayor grado de privacidad y reduce la superficie de ataque en escenarios donde no necesitas o no quieres la integración con los servicios online de la compañía.
En entornos con varios usuarios compartiendo PC (familia numerosa, despacho, aula, laboratorio o pequeña empresa) crear perfiles locales separados evita que unos vean los datos de otros, aísla configuraciones, historial del navegador, aplicaciones instaladas para cada usuario y simplifica el cumplimiento de políticas de protección de datos.
Windows 8, 10 y 11 siguen permitiendo cuentas locales igual que en versiones anteriores, aunque el sistema intente empujarte a usar cuentas de Microsoft para todo. Puedes alternar en cualquier momento de cuenta Microsoft a cuenta local y viceversa, sin perder datos si lo haces correctamente.
Cuentas locales de usuario y de sistema: qué tipos hay y para qué sirven
Windows crea automáticamente una serie de cuentas locales predeterminadas cuando instalas el sistema. Algunas son de usuario y otras son de sistema, usadas internamente por el propio Windows y por ciertos servicios. No se comportan igual ni tienen los mismos permisos, así que conviene conocerlas para no romper nada ni dejar puertas abiertas.
Cuentas de usuario locales predeterminadas
Las cuentas de usuario locales predeterminadas son cuentas integradas que el sistema genera durante la instalación. No se pueden eliminar, aunque sí renombrar o deshabilitar en algunos casos. Todas residen en el equipo y solo tienen derechos sobre ese dispositivo, sin acceso automático a recursos de red.
Para ver y administrar estas cuentas, en ediciones Pro y superiores puedes usar la consola Administración de equipos > Usuarios y grupos locales > Usuarios. Desde ahí es posible crear usuarios personalizados, cambiar contraseñas, deshabilitar cuentas, etc. En ediciones Home, muchas de estas tareas se realizan desde la app de Configuración o mediante comandos.
Cuenta Administrador (Administrator)
La cuenta de administrador local integrada es la que tiene el control total del equipo. Su SID termina en 500 y es la primera cuenta que se genera durante la instalación de Windows, aunque en versiones modernas suele quedar deshabilitada y se crea otra cuenta con permisos de administrador para el usuario principal.
Con esta cuenta se puede modificar cualquier archivo, servicio, permiso o configuración, tomar posesión de recursos, cambiar derechos de usuario y asignar privilegios. Precisamente por eso, es una cuenta muy atractiva para atacantes y malware, y su existencia es bien conocida en prácticamente todas las versiones de Windows.
Por motivos de seguridad, no puedes borrar la cuenta Administrador, pero sí puedes renombrarla o dejarla deshabilitada. Microsoft recomienda no usarla para iniciar sesión de forma habitual y limitar al máximo el número de cuentas que pertenezcan al grupo Administradores. Una buena práctica es trabajar siempre con una cuenta estándar y usar la elevación de privilegios (Ejecutar como administrador y UAC) solo cuando proceda.
Cuenta Invitado (Guest)
La cuenta Invitado está pensada para usuarios ocasionales o de un solo uso que necesitan acceso rápido a un equipo sin crear una cuenta propia. Su SID termina en 501, tiene permisos muy limitados y, por diseño, sirve para sesiones temporales sin personalización profunda.
Por defecto, la cuenta Invitado viene deshabilitada y sin contraseña, lo que supone un riesgo serio si se activa sin cuidado, ya que puede ofrecer acceso anónimo. Es el único miembro del grupo integrado Invitados (SID S-1-5-32-546), que solo cuenta con los derechos imprescindibles para iniciar sesión localmente.
Si llegas a habilitarla por algún motivo, lo recomendable es restringirla al máximo, no permitir su uso a través de la red, impedir que vea registros de eventos y revisar su actividad con frecuencia para evitar que alguien la use para dejar servicios o recursos abiertos sin querer.
Cuenta DefaultAccount (DSMA)
DefaultAccount, también conocida como Default System Managed Account (DSMA), es una cuenta estándar gestionada por el sistema que se introduce para soportar aplicaciones multiusuario (MUMA) y determinados escenarios modernos (por ejemplo, Xbox o entornos de sesión compartida).
Esta cuenta suele estar deshabilitada por defecto en Windows de escritorio y en servidores con experiencia de escritorio. Tiene un RID conocido (503) y pertenece al grupo especial de cuentas administradas del sistema (SID S-1-5-32-581). El propio Windows la crea en el Administrador de cuentas de seguridad (SAM) la primera vez que arranca el equipo.
Desde el punto de vista de permisos se comporta como un usuario estándar, pero está pensada para que las aplicaciones que deben permanecer en segundo plano, reaccionando a cambios de sesión de usuario, se ejecuten en un contexto independiente al de los usuarios humanos. Microsoft desaconseja modificar su configuración predeterminada, ya que podría romper escenarios actuales o futuros sin aportar beneficios de seguridad reales.
Cuenta WDAGUtilityAccount
WDAGUtilityAccount es otra cuenta local integrada, usada por Protección de aplicaciones de Windows Defender (Windows Defender Application Guard). Su SID es conocido (termina en 504) y, por defecto, no pertenece a ningún grupo.
Esta cuenta se utiliza para aislar entornos de navegación o ejecución que el sistema protege en contenedores. En condiciones normales no debes tocarla: Windows la habilita y configura automáticamente cuando hace falta.
Cuenta WSIAccount
WSIAccount aparece en Windows 11 y está orientada a las actividades relacionadas con la web desde la pantalla de bloqueo o inicio de sesión. Se emplea, por ejemplo, para acceder a páginas del proveedor de credenciales cuando se quiere restablecer una contraseña o usar autenticación basada en web antes de iniciar sesión totalmente.
Tiene un SID conocido que termina en 1001 y, por defecto, forma parte del grupo Usuarios. De nuevo, es una cuenta de servicio que no se debe usar de forma interactiva ni modificar manualmente salvo que Microsoft lo documente para algún caso concreto.
Cuenta HelpAssistant
HelpAssistant es una cuenta local que Windows habilita solo durante las sesiones de Asistencia remota. Cuando un usuario solicita ayuda mediante invitación (por correo, archivo, etc.), el sistema crea esta cuenta con permisos limitados para que la persona que asiste pueda conectarse y controlar el equipo bajo supervisión.
Mientras no haya solicitudes de ayuda remota pendientes, la cuenta se mantiene deshabilitada. Está gestionada por el servicio Administrador de sesiones de Ayuda de Escritorio remoto y forma parte de grupos relacionados con Escritorio remoto y Terminal Server (por ejemplo, los grupos con SID S-1-5-13 y S-1-5-14, que incluyen usuarios de servicios de Escritorio remoto e inicio de sesión interactivo remoto).
En Windows Server, la Asistencia remota no viene instalada de serie y es un componente opcional. Hasta que no se instala y se usa, la cuenta HelpAssistant no entra realmente en juego.
Cuentas de sistema locales: SYSTEM, Servicio local y Servicio de red
Además de las cuentas de usuario, Windows dispone de varias cuentas internas de sistema que no están pensadas para iniciar sesión como un usuario normal, sino para que el propio sistema y sus servicios funcionen.
La más potente es la cuenta SYSTEM (SID S-1-5-18). La utilizan el núcleo del sistema operativo y multitud de servicios que necesitan permisos máximos, incluyendo tareas de instalación. No aparece en el Administrador de usuarios ni se puede añadir a grupos, pero sí la verás en las listas de permisos NTFS, donde suele tener control total sobre todos los archivos de los volúmenes locales.
La cuenta Servicio local (LOCAL SERVICE, SID S-1-5-19) está pensada para ejecutar servicios con privilegios mínimos en el equipo y credenciales anónimas en la red. De esta forma, si un servicio que usa esta cuenta se ve comprometido, el atacante tiene menos margen de maniobra.
Por su parte, la cuenta Servicio de red (NETWORK SERVICE, SID S-1-5-20) ejecuta servicios que necesitan usar las credenciales del propio equipo cuando se comunican con otros servidores remotos. Así, el servicio se presenta ante la red como el ordenador, no como un usuario cualquiera, pero manteniendo privilegios relativamente acotados en local.
Crear cuentas locales seguras para el uso diario en Windows 10 y Windows 11
Más allá de las cuentas integradas, lo habitual es crear usuarios locales estándar para uso diario y una o varias cuentas de administración que solo se utilicen cuando haya que instalar software, modificar ajustes globales o hacer mantenimiento. Windows ofrece varios caminos para crear estas cuentas, según prefieras interfaz gráfica o consola.
Creación desde la app Configuración
En Windows 10 y 11, la ruta más “amigable” para la mayoría de usuarios es la app Configuración > Cuentas. Desde ahí se puede crear tanto cuentas locales como basadas en Microsoft ID, y cambiarles posteriormente el tipo (Usuario estándar o Administrador).
El flujo típico es: ir a Cuentas, entrar en Familia y otros usuarios (en Windows 10) o en Otros usuarios (en Windows 11), pulsar en Agregar cuenta y, cuando el sistema pida un correo o teléfono, escoger la opción No tengo los datos de inicio de sesión de esta persona. En el siguiente paso, en lugar de abrir un correo nuevo de Microsoft, se elige Agregar un usuario sin cuenta Microsoft.
A partir de ahí solo hay que indicar nombre de usuario y contraseña, repetir la contraseña por seguridad y establecer tres preguntas y respuestas de recuperación. Es posible dejar la contraseña en blanco, pero es mala idea en casi cualquier escenario real. Una vez creada, la cuenta aparece en la sección de otros usuarios y es posible cambiar su tipo a Administrador si fuera necesario.
Creación como miembro de la familia (con cuenta Microsoft)
Si quieres crear cuentas para menores o usuarios a los que quieras aplicar controles parentales y reglas de tiempo de pantalla, puedes usar la opción de Familia. En este caso sí se requiere una cuenta de Microsoft, porque el control se centraliza a través del servicio Family Safety.
Un usuario con privilegios de administrador que haya iniciado sesión con una ID de Microsoft puede ir a Cuentas > Familia, agregar un miembro, indicar si será Organizador o Miembro y asociar su correo electrónico (o crear uno nuevo para un niño). Toda la configuración posterior (filtros, límites, informes) se gestiona después desde la web de Microsoft Family Safety.
Creación desde Administración de equipos
En entornos más técnicos, Administración de equipos es una herramienta muy cómoda para crear rápidamente varios usuarios locales, sobre todo en Windows Pro o Enterprise.
Desde el menú contextual del botón Inicio se abre Administración de equipos, se expande Usuarios y grupos locales > Usuarios, y se usa la opción de Nuevo usuario. Ahí se definen nombre de usuario, nombre completo opcional, descripción y contraseña. Es posible exigir el cambio de contraseña en el primer inicio de sesión, prohibir que el usuario la cambie o marcar que nunca caduca.
Tras pulsar en Crear, la ventana permanece abierta por si necesitas generar varios usuarios seguidos, algo muy útil en aulas o laboratorios con muchos alumnos. Este método solo crea usuarios locales, no cuentas de Microsoft, y desde las propiedades de cada usuario se le puede asignar pertenencia a grupos (por ejemplo, Usuarios o Administradores).
Creación con Netplwiz
Netplwiz es una herramienta clásica de Windows para gestionar cuentas y opciones de inicio de sesión. Se lanza desde Ejecutar escribiendo netplwiz y permite agregar cuentas, cambiar contraseñas y configurar si un usuario debe introducir contraseña al iniciar sesión.
Desde la pestaña Usuarios se pulsa Agregar y el asistente ofrece crear una cuenta de Microsoft o, si se escoge la opción adecuada, una cuenta local sin Microsoft. Aunque está algo escondido, el procedimiento es similar al de la app Configuración: nombre, contraseña y, si procede, pertenencia a grupos.
Creación desde consola: net user y PowerShell
Cuando gestionas muchos equipos o trabajas en modo seguro, la consola es tu aliada. Con el comando clásico net user puedes crear un usuario con una sola línea, por ejemplo:
net user operador ContraseñaSegura123! /add
Si después quieres que esa cuenta pertenezca a un grupo concreto, puedes usar:
net localgroup Administrators operador /add para asignarle privilegios de administrador, o bien añadirla al grupo Users si solo debe ser estándar. Esta vía es ideal para scripts y despliegues automatizados.
En PowerShell, el cmdlet New-LocalUser permite más control y una sintaxis moderna. Puedes crear la cuenta y definir una contraseña segura convertida a SecureString, y después usar Add-LocalGroupMember para añadirla al grupo correspondiente. Para administradores de sistemas resulta especialmente práctico cuando se combina con herramientas de automatización o con el módulo Microsoft.PowerShell.LocalAccounts.
Cambios recientes en Windows 11: OOBE, comandos y creación de cuentas locales
En versiones recientes de Windows 11, especialmente a partir de la compilación 24H2, Microsoft ha ido cerrando vías “no oficiales” para saltarse la exigencia de usar cuenta Microsoft durante la instalación inicial.
El conocido truco OOBE\BYPASSNRO, que hasta hace poco permitía forzar la opción de cuenta local en el asistente OOBE (Out-of-Box Experience), dejó de funcionar. Al intentar usarlo en 24H2, el sistema simplemente reinicia el asistente y te devuelve a la misma pantalla, sin ofrecer el atajo a cuenta local como antes.
Sin embargo, siguen quedando alternativas eficaces. Una de las más limpias es, en la pantalla de obligatoriedad de conexión a Internet, usar Shift+F10 para abrir una consola y ejecutar un comando interno como OOBE: start ms-cxh:localonly, que hace que el asistente muestre la ruta de creación de cuenta local sin asociarla a un correo.
Otra opción clásica es instalar Windows sin conexión, desconectando el cable de red o deshabilitando la Wi-Fi antes o durante el asistente. En muchos builds, si el equipo no detecta Internet, ofrece automáticamente la posibilidad de crear una cuenta local como parte del proceso de instalación inicial, sin necesidad de trucos adicionales.
Por último, siempre queda la vía de instalar con una cuenta de Microsoft y después crear una cuenta local desde Configuración o consola, mover el uso diario a esa cuenta y, si se desea, convertir la cuenta Microsoft a local desde Cuentas > Tu información > Iniciar sesión con una cuenta local. Es un poco más largo, pero completamente soportado y estable.
Seguridad y buenas prácticas en el uso diario de cuentas locales
Tener muchas cuentas no sirve de nada si su configuración es laxa. Para que las cuentas locales realmente aporten seguridad, hay que combinar buenas prácticas de uso con la configuración correcta de UAC, permisos y políticas de grupo, especialmente en entornos corporativos.
Usar cuenta estándar para el día a día
La recomendación general de Microsoft y de cualquier experto en seguridad es clara: utiliza una cuenta estándar para las tareas diarias (navegar, correo, ofimática, juegos, etc.) y reserva las cuentas con permisos de administrador solo para aquellas acciones que realmente lo exijan, y, siempre que sea posible, activa autenticación multifactor.
El Control de cuentas de usuario (UAC) ayuda mucho en esto. Incluso iniciando sesión con una cuenta que pertenece al grupo Administradores, UAC aplica un modelo de “aprobación de administrador”: el usuario funciona en modo estándar hasta que una acción requiere elevación, momento en el que el sistema muestra un aviso y pide confirmación o credenciales.
UAC también afecta a cómo se comportan las cuentas locales cuando se usan para acceso remoto o de red. Por ejemplo, al iniciar sesión mediante un logon de red (NET USE, conexiones compartidas, etc.), Windows puede emitir un token de usuario estándar sin capacidad de elevación, impidiendo que esa cuenta acceda a recursos administrativos como C$ o ADMIN$. Esto reduce la superficie para movimientos laterales tras un robo de credenciales.
Restringir el uso remoto de cuentas locales con derechos administrativos
Uno de los ataques más comunes en redes Windows es el movimiento lateral aprovechando hashes de contraseñas reutilizados en múltiples equipos. Si la cuenta local de administrador tiene la misma contraseña en varios PCs, un atacante que comprometa uno puede usar esas credenciales para expandirse al resto.
Para mitigar este riesgo, existen varias estrategias complementarias. La primera es denegar el inicio de sesión desde la red y el inicio de sesión por Servicios de Escritorio remoto a las cuentas locales que sean miembros del grupo Administradores. Se hace mediante directivas de grupo, usando las políticas:
- Denegar el acceso desde la red a este equipo, configurada para “Cuenta local y miembro del grupo Administradores”.
- Denegar inicio de sesión a través de Servicios de Escritorio remoto, también apuntando a “Cuenta local y miembro del grupo Administradores”.
Estas políticas se aplican en Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Asignación de derechos de usuario y se distribuyen vía GPO a las unidades organizativas que contengan estaciones de trabajo y servidores que quieras proteger.
Otra medida clave es controlar el comportamiento de UAC en accesos remotos configurando el valor de registro LocalAccountTokenFilterPolicy bajo HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. A través de un GPO basado en Preferencias de Registro se puede definir este valor como REG_DWORD con datos 0 para imponer filtrado de tokens y limitar la elevación de cuentas locales sobre la red.
Contraseñas únicas y aleatorias para cuentas locales con privilegios
Reutilizar la misma contraseña local de administrador en todos los equipos es un riesgo enorme. Cualquier filtración de esa contraseña, o de su hash, abre la puerta a comprometer en cadena todas las máquinas configuradas igual.
La solución pasa por establecer contraseñas únicas y aleatorias para cada cuenta local con privilegios. Esto dificulta muchísimo ataques de tipo pass-the-hash, ya que un hash robado solo sirve en el equipo donde se obtuvo, no en el resto.
Microsoft ofrece varias formas de automatizar esta aleatorización. La más recomendable a día de hoy es implementar LAPS (Local Administrator Password Solution), que se encarga de generar y rotar contraseñas complejas para las cuentas de administrador local y almacenarlas cifradas en directorio activo, accesibles solo para administradores autorizados. Otras posibilidades incluyen adquirir herramientas empresariales de gestión de contraseñas privilegiadas o desarrollar scripts personalizados que generen contraseñas fuertes de forma periódica. Lo importante es huir de las contraseñas estáticas compartidas y de la tentación de “poner la misma en todos para acordarse”.
Proteger credenciales y procesos sensibles: LSASS y Credential Guard
Windows almacena credenciales y secretos de seguridad en el proceso LSASS (Local Security Authority Subsystem Service), que controla las sesiones y validaciones de usuario. Si un atacante consigue leer la memoria de LSASS, puede extraer hashes de contraseñas y tickets de Kerberos para movimientos laterales. Además, conviene comprobar si tus credenciales han sido filtradas y actuar rápidamente.
Por eso, en estaciones de trabajo y servidores modernos conviene configurar LSASS como un Process Protection Light (PPL), reforzando su aislamiento frente a procesos no confiables. Adicionalmente, en muchos equipos actuales es posible activar Credential Guard, que usa virtualización basada en hardware para aislar credenciales y secretos, reduciendo también la superficie para robo de hashes.
Estas medidas se suman a la correcta segmentación de cuentas locales, el uso de contraseñas únicas y la restricción de inicios de sesión remotos, dando como resultado un entorno mucho más resistente a ataques de escalada y movimiento lateral.
Gestión avanzada de cuentas locales y administración remota
En controladores de dominio, las cuentas de dominio se gestionan a través de Active Directory y las herramientas habituales, pero también es posible usar Usuarios y grupos locales para administrar cuentas en equipos remotos que no sean controladores de dominio, siempre que la red y las políticas permitan la administración remota.
Además de la GUI, los administradores disponen de utilidades clásicas como NET.EXE USER y NET.EXE LOCALGROUP para la gestión de usuarios y grupos locales mediante scripts, y del módulo Microsoft.PowerShell.LocalAccounts para automatizar creación, modificación y eliminación de cuentas con PowerShell.
Asignar correctamente derechos de usuario y permisos de acceso también es fundamental. Los derechos (como hacer copia de seguridad de archivos, apagar el equipo, iniciar sesión localmente o por red) se definen en las directivas de seguridad locales o de dominio, mientras que los permisos se aplican a objetos concretos (archivos, carpetas, impresoras) a través de ACLs.
En controladores de dominio, no se pueden usar Usuarios y grupos locales para administrar cuentas locales del propio controlador, pero sí para dirigir la administración hacia equipos miembro remotos. Esta separación ayuda a mantener la seguridad del dominio bien delimitada frente a las cuentas locales de cada máquina.
En conjunto, conocer bien las cuentas integradas, usar cuentas locales estándar para el día a día, limitar estrictamente las cuentas administrativas, aplicar políticas de restricción de inicios de sesión remotos, proteger LSASS y garantizar contraseñas únicas pone las bases para que las cuentas locales sean una herramienta segura y fiable tanto en el hogar como en redes empresariales, aulas o laboratorios donde muchos usuarios comparten equipos pero no deberían compartir riesgos ni datos.
