Control de acceso como servicio (ACaaS): qué es y por qué es importante

28 de septiembre de 2026

Comprar un sistema de control de acceso solía implicar un proyecto de inversión: un servidor, armarios de controladores en el patinillo de instalaciones, cableado hasta cada puerta y un contrato de mantenimiento para que todo siguiera funcionando. El control de acceso como servicio sustituye ese proyecto por una suscripción y traslada el software, las actualizaciones y la consola de gestión a una plataforma que gestiona otra empresa. Esta guía explica qué abarca el ACaaS en seguridad física, cómo se monta realmente una implantación, cómo es la estructura de costes cuando el software es una suscripción y no una compra, y en qué casos el modelo deja de tener sentido. También recoge las preguntas que conviene plantear a un proveedor antes de firmar un contrato.

En este artículo, el control de acceso se refiere a la entrada física a edificios y salas: puertas, cerraduras, lectores y credenciales. En TI se usa la misma expresión para los permisos sobre archivos, aplicaciones y redes. Esta página trata del control de acceso a edificios.

Índice

¿Qué es el control de acceso como servicio?

El control de acceso como servicio (ACaaS, por sus siglas en inglés) es un modelo de prestación en el que el software que gestiona quién puede abrir cada puerta funciona como un servicio de suscripción, alojado y mantenido por el proveedor, y en las instalaciones solo se instala el hardware de las puertas. El cliente paga periódicamente por la plataforma en lugar de comprar un sistema y ser su propietario.

La sigla ACaaS sigue el mismo patrón que SaaS (software como servicio), y la analogía es exacta, no decorativa. En ambos casos, el proveedor opera la aplicación, se accede a ella desde un navegador, se actualiza de forma centralizada y se paga mediante suscripción. La diferencia es que el control de acceso tiene además una capa física, por lo que el ACaaS nunca elimina por completo el hardware del edificio. Las cerraduras, los lectores y las credenciales se quedan donde están.

Merece la pena nombrar directamente tres cosas que el cliente deja de poseer, porque explican la mayor parte de la diferencia operativa:

El servidor. No hay ninguna máquina en un rack ejecutando la base de datos de control de acceso, ni un sistema operativo debajo que haya que parchear, copiar o sustituir al final de su vida útil.

La versión del software. La plataforma se mantiene en una única versión actualizada para todos los clientes, así que no existe una versión local que se vaya quedando atrás.

El proyecto de actualización. Las nuevas funciones llegan como parte del servicio, y no como un trabajo que hay que definir, presupuestar y planificar.

Lo que queda es la parte que tiene que ser física: el hardware de las puertas, las credenciales que llevan las personas y la decisión sobre quién puede pasar por cada puerta. El ACaaS cambia dónde se registra y se administra esa decisión, no en qué consiste.

El ACaaS en seguridad física no es la gestión de accesos en la nube para sistemas de TI

En seguridad física, el control de acceso se refiere a puertas, cerraduras, lectores y las credenciales que las abren. En este sentido, el ACaaS es un sistema del edificio: una plataforma alojada en la nube que almacena los permisos y horarios de los puntos de entrada físicos, ya sean puertas perimetrales, salas de reuniones, almacenes, patinillos de instalaciones o racks de servidores concretos.

En TI, la misma expresión abarca el acceso a archivos, aplicaciones, redes y datos. Ese ámbito tiene su propio vocabulario, como el control de acceso basado en roles (RBAC), el control de acceso basado en atributos (ABAC) y las listas de control de acceso (ACL), y se ocupa de lo que una cuenta autenticada puede hacer dentro de un sistema, no de qué puerta puede abrir.

Son disciplinas realmente distintas, y una página sobre una de ellas no le sirve de mucho a quien busca la otra. Pero coinciden en un punto concreto y cada vez más habitual: el directorio de identidades.

Cuando una plataforma de acceso físico se alimenta del mismo directorio que controla el inicio de sesión en el correo electrónico y las aplicaciones, una sola acción administrativa actualiza ambos. Al desactivar la cuenta de un empleado que causa baja, se eliminan a la vez su acceso al portátil y al edificio, sin una segunda solicitud a otro equipo. Esa convergencia es la razón por la que los dos significados de la expresión no dejan de cruzarse, y también el argumento práctico más sólido a favor del control de acceso físico en la nube en una organización que ya utiliza un directorio de identidades en la nube.

Cómo se monta una implantación de ACaaS

Una implantación de control de acceso alojado tiene tres partes: lo que se queda en el edificio, lo que funciona como servicio de control de acceso y la forma en que las personas y sus permisos llegan al sistema.

¿Qué se queda en el edificio?

El hardware de las puertas y, en la mayoría de los casos, muy poco más. Cada puerta controlada lleva una cerradura o un lector. Los accesos con más tránsito, como una entrada principal o una línea de tornos, suelen tener alimentación de red y conexión permanente. Las puertas que se usan con menos frecuencia suelen llevar cerraduras inalámbricas a pilas, que guardan sus permisos localmente y se sincronizan periódicamente en lugar de mantener una conexión continua.

La consecuencia merece decirse con claridad: no hace falta reservar espacio en una sala de servidores, no hay armario de controladores en el patinillo y, en una implantación inalámbrica, no hay que tender cable hasta cada puerta. Esto último es lo que hace viable instalar el sistema en un edificio ya ocupado, porque el trabajo se limita a la hoja de la puerta, en vez de pasar por techos y paredes en una planta en uso. También es la razón por la que los despliegues en varios emplazamientos se volvieron viables para organizaciones sin personal técnico en cada ubicación.

¿Qué funciona como servicio?

La plataforma de gestión almacena los permisos, los grupos de usuarios, los horarios, el historial de eventos y los informes, y se accede a ella desde un navegador; las acciones diarias y la configuración también están disponibles en una app. Es en esta capa donde tienen cabida las preguntas sobre la seguridad del control de acceso en la nube, ya que es donde se almacenan y administran los datos de acceso.

La diferencia operativa que los clientes notan primero parece menor de lo que es y resulta más importante de lo esperado: las actualizaciones llegan sin necesidad de un proyecto. No hay una versión a la que planificar una migración, ni una matriz de compatibilidad que comprobar con el sistema operativo de un servidor, ni una ventana de mantenimiento que reservar.

¿Cómo se incorporan las personas y los permisos?

Hay dos vías, y la mayoría de las implantaciones utilizan ambas. Los empleados se sincronizan desde el directorio de identidades de la organización, normalmente Microsoft Entra ID, de modo que aparecen cuando se incorporan, cambian de acceso cuando cambian de puesto y lo pierden cuando se van, sin una lista paralela que mantener. Todos los demás, como contratistas, personal de limpieza, proveedores y visitantes, se dan de alta directamente en la plataforma, normalmente con una fecha de caducidad asignada desde el principio.

Los visitantes son el caso que marca la diferencia entre plataformas, ya que normalmente necesitan acceso durante unas horas y no van a instalar una app para conseguirlo. Algunas plataformas lo resuelven con un código temporal emitido con antelación. ATLAS, por ejemplo, genera un código QR con una franja horaria de entrada definida que se envía al Wallet de Apple o Android del visitante y que lee un poste de intercomunicación de Commend (que puede implantarse de forma independiente a ATLAS) en la entrada, de modo que el visitante llega con el acceso ya preparado y sin nada que descargar.

Las plataformas de esta categoría, como ATLAS Access, control de acceso en la nube, suelen ofrecer tanto integración nativa con directorios como una API REST para los sistemas de identidad que no son compatibles de forma nativa.

El modelo comercial: ¿qué deja de comprar y qué empieza a pagar?

El ACaaS suele describirse como un paso de CapEx a OpEx. Es cierto, pero una conversación sobre presupuestos necesita más detalle del que aporta esa idea. Resultan más útiles tres categorías.

Lo que se compra una vez	Lo que se paga periódicamente	Lo que ya no se compra
Cerraduras y lectores para cada puerta	Suscripción a la plataforma, normalmente con precio por puerta, por usuario o por emplazamiento, con soporte y actualizaciones incluidos	Hardware del servidor y su ciclo de sustitución
Mano de obra de instalación y puesta en marcha	Pilas de repuesto para las cerraduras inalámbricas	Licencias del sistema operativo y de la base de datos del servidor
Credenciales físicas, incluidas las tarjetas maestras o de emergencia	Sustitución de credenciales físicas, cuando se siguen emitiendo tarjetas	Armarios de controladores y sus envolventes
Cableado de los lectores conectados a la red eléctrica en las puertas con más tránsito	Conservación ampliada o archivo de eventos, cuando se cobra aparte	Cableado hasta cada puerta, en implantaciones inalámbricas
		Proyectos de actualización de versión y mantenimiento del software on-premise

El control de acceso por suscripción suele tener un precio basado en una unidad que crece con el tamaño de las instalaciones, en lugar de una licencia única: por puerta, por usuario o por emplazamiento, a veces con niveles que desbloquean funciones adicionales. La unidad importa más que la tarifa de referencia, porque un edificio con muchas puertas y pocas personas tiene un precio muy distinto al de uno con pocas puertas y una alta rotación de personal; por eso, la unidad de precio es lo primero que hay que aclarar al comparar presupuestos.

La interpretación honesta es esta: a cinco años, el total puede no ser inferior al de un sistema en propiedad. Lo que cambia es la forma del gasto: empieza siendo menor, es predecible, absorbe actualizaciones que de otro modo llegarían como solicitudes de inversión imprevistas y pasa de un proceso de aprobación de inversiones a una partida del presupuesto operativo. Para muchas organizaciones, esa reclasificación es la verdadera razón por la que el modelo se impone, no los números.

¿Qué cambia para las personas que gestionan el edificio?

Hay tres funciones que asumen las consecuencias de este modelo, y cada una lo vive de forma distinta.

El responsable de instalaciones (administrador del sistema)

Los cambios de acceso rutinarios dejan de ser incidencias. Dar acceso a un contratista a una puerta durante una tarde, emitir una credencial para un nuevo empleado o retirar el acceso a alguien que se ha ido se convierte en una tarea que se completa en un navegador o una app en menos de un minuto, en lugar de una solicitud a quien tenga los permisos de administración. Esto es especialmente importante cuando el acceso se necesita de inmediato. Normalmente se sabe con días de antelación que va a incorporarse alguien, así que incluso un proceso lento funciona. Pero un visitante que espera en recepción o un técnico al que se llama para una reparación urgente necesita acceso ya, y es justo entonces cuando esperar a que otra persona actúe se convierte en un problema.

La contrapartida es que la capacidad trae consigo la responsabilidad. Cuando la administración de accesos es realmente autoservicio, pasa a ser realmente tarea del equipo de instalaciones.

El responsable de TI

Nada que parchear, ninguna base de datos de la que hacer copias de seguridad y ningún servidor al final de su vida útil que presupuestar. A cambio, aparecen dos nuevas responsabilidades. La primera es la evaluación del proveedor. Los datos de acceso pasan a estar en manos de un tercero y, según el RGPD, el cliente sigue siendo el responsable del tratamiento y el proveedor actúa como encargado del tratamiento, por lo que las obligaciones propias de la organización no cambian. Esto es lo habitual en cualquier servicio en la nube y se gestiona mediante un acuerdo de tratamiento de datos, que establece qué puede hacer el proveedor con los datos, dónde se almacenan y qué ocurre cuando finaliza el contrato. Leer ese acuerdo forma parte de la evaluación. La segunda es la integración de identidades. Si la sincronización deja de funcionar, no se rompe nada de forma visible, pero los cambios dejan de llegar, de modo que un empleado que se ha ido conserva su acceso hasta que alguien se da cuenta. Esto ocurre con cualquier sistema alimentado desde un directorio, aunque es nuevo para las organizaciones cuyo antiguo control de acceso mantenía su propia lista de usuarios independiente.

El instalador o integrador

Menos cableado, menos puesta en marcha y mucho menos tiempo en las instalaciones. La configuración se hace con una app junto a la puerta, en lugar de en un puesto de trabajo en una sala técnica, y normalmente una cerradura puede incorporarse al sistema en mucho menos de un minuto. Menos infraestructura también significa menos coste de instalación, lo que cambia qué resulta económicamente viable proteger: puertas que nunca compensaba cablear pasan a merecer un control de acceso.

Lo que sustituye al cableado es la gestión del firmware y de las pilas en un parque distribuido de dispositivos inalámbricos. Es una carga menor que una red de controladores, pero no desaparece, y conviene acordar quién se encarga de ella antes de la entrega.

¿Dónde encaja el ACaaS y dónde sigue siendo mejor un sistema on-premise?

Elija ACaaS cuando:

Opera en varios emplazamientos y quiere una única consola para todos ellos
El acceso debe poder administrarse desde dondequiera que esté el responsable
Los derechos de acceso cambian con frecuencia, por la rotación de personal, los visitantes o el tránsito de contratistas
Es un inquilino sin sala de servidores y sin intención de tenerla
Está instalando el sistema en un edificio ocupado donde el cableado causa molestias
Ya tiene estandarizado un directorio de identidades en la nube
Su empresa no cuenta con un equipo de TI propio en las instalaciones
para mantener servidores, aplicar parches al software o gestionar copias de seguridad
La integración con otros servicios en la nube (sistemas de RR. HH., gestión de visitantes) es más fácil de desarrollar

Mantenga un sistema on-premise cuando:

Las normas del emplazamiento no permiten que los sistemas de seguridad se conecten a internet
Sus lectores o credenciales actuales no son compatibles con la plataforma y a ese hardware aún le quedan años de vida útil
Las normas internas prohíben que los datos de acceso salgan de su propia infraestructura
El número de puertas es tan elevado que la suscripción recurrente al software supera el coste de una licencia única (en la mayoría de las implantaciones, el hardware se compra y solo el software es una suscripción, por lo que el ACaaS no es un modelo de alquiler de cerraduras y lectores)
Necesita unificar el acceso con el vídeo, la intrusión y los sistemas del edificio en una única plataforma

Los edificios multiinquilino encajan claramente en la primera columna, y por una razón estructural concreta. El administrador del inmueble puede delegar la administración diaria de los accesos en el responsable de cada inquilino sin darle permisos más allá de su propio espacio, de modo que no tiene que atender todas las solicitudes rutinarias de cada ocupante. Esa delegación es difícil de organizar cuando el sistema es una única instalación en propiedad con una sola consola de administración.

Las dos columnas no son categorías permanentes. Los proveedores que ofrecen plataformas tanto alojadas como on-premise normalmente pueden plantear una vía de migración entre ellas, algo importante para las organizaciones cuyas necesidades avanzan en una dirección, pero aún no han llegado a destino.

Preguntas que hacer a un proveedor de ACaaS antes de firmar

Estas ocho preguntas están redactadas para incorporarlas directamente a un pliego de contratación. Cada una tiene un motivo, y la respuesta a cada una debería llegar por escrito, no en una reunión.

¿Qué disponibilidad se garantiza y qué ocurre si no se cumple? La disponibilidad (uptime) es el porcentaje de tiempo durante el que se garantiza que la plataforma está operativa, y se indica en el acuerdo de nivel de servicio (SLA). Una cifra contractual no es lo mismo que una afirmación comercial sobre fiabilidad, y la compensación cuando no se alcanza esa cifra importa tanto como la propia cifra.
¿Dónde se almacenan los datos y podemos exigir una región concreta? La residencia de los datos es una cuestión contractual, no técnica. Si su organización necesita que los datos de acceso permanezcan en una jurisdicción determinada, ese requisito debe figurar en el contrato, junto con el acuerdo de tratamiento de datos del proveedor.
¿Qué puertas siguen funcionando durante un corte de internet y durante cuánto tiempo? Pregunte dónde se toma la decisión de acceso. Si los permisos se almacenan en la puerta o en un controlador local, las personas autorizadas siguen pudiendo entrar y los eventos se cargan más tarde. Si una puerta depende de que la plataforma responda en ese momento, no. Pida la respuesta por tipo de puerta y pregunte cuánto tiempo siguen siendo válidos los permisos almacenados antes de que el hardware necesite sincronizarse.
¿Durante cuánto tiempo se conservan por defecto los eventos de acceso y qué opciones hay si necesitamos conservarlos más? La conservación es el periodo durante el que la plataforma guarda los registros de eventos antes de eliminarlos, y varía mucho de una plataforma a otra. Si tiene una obligación de auditoría o de seguros que exige un historial determinado, compruebe el periodo por defecto antes de dar por hecho que cumple esa obligación, y confirme qué implica ampliarlo.

¿Cómo podemos extraer nuestros datos de eventos de acceso, en qué formato, mediante qué interfaz y con qué preaviso? La exportación es lo que permite conservar los eventos más allá del periodo de conservación de la plataforma, así que, si necesita un historial más largo que el predeterminado, este es el mecanismo que lo hace posible. También determina qué puede llevarse si cambia de proveedor. Una API REST, una exportación programada o un formato de archivo documentado son respuestas válidas.
¿Qué directorios de identidades son compatibles de forma nativa y no mediante un conector? Una integración nativa conecta la plataforma de acceso directamente con su directorio. Un conector es un software independiente intermedio, lo que supone un componente más que mantener y una parte más implicada cuando la sincronización deja de funcionar.
¿Quién es responsable de las actualizaciones de firmware y de las pilas de las cerraduras? En un parque inalámbrico distribuido, esto supone un trabajo recurrente real. El contrato debe asignarlo a alguien con nombre, ya sea el cliente, el integrador o el proveedor.
¿Qué ocurre con el hardware instalado si rescindimos el contrato? La propiedad varía. Las cerraduras y los lectores pueden comprarse, alquilarse o incluirse en la suscripción, y eso determina si son suyos. Conviene confirmar otros dos aspectos: si el hardware puede reconfigurarse para funcionar con la plataforma de otro proveedor y si sigue funcionando una vez finalizada la suscripción. En conjunto, estos factores determinan cuánto cuesta realmente dejar el servicio.

La conservación y la exportación merecen especial atención cuando la organización tiene obligaciones de auditoría, ya que esas dos respuestas determinan si podrá aportar pruebas cuando se las pidan. En la UE, por ejemplo, la Directiva NIS2 exige a las organizaciones incluidas en su ámbito adoptar medidas de gestión de riesgos que abarquen la seguridad física y el control de acceso, y poder demostrarlas, lo que convierte los periodos de conservación y las vías de exportación en una cuestión práctica, no teórica.

El mercado del ACaaS: ¿qué impulsa su adopción?

El mercado del control de acceso como servicio está creciendo por motivos que tienen poco que ver con el propio control de acceso y mucho con lo que ha cambiado a su alrededor.

Cuatro factores explican la mayor parte. En primer lugar, otros sistemas del edificio pasaron antes a la nube, de modo que el vídeo, la gestión técnica del edificio y los sistemas de visitantes ya habían normalizado la idea de una plataforma alojada antes de que el control de acceso siguiera el mismo camino. En segundo lugar, el trabajo híbrido cambió los patrones de ocupación, y un edificio en el que la asistencia varía de un día a otro es más difícil de gestionar con permisos asignados de forma estática y llaves físicas. En tercer lugar, la rotación de personal encareció de forma desproporcionada la administración de tarjetas, porque el coste de una credencial no es la tarjeta, sino el trabajo de emitirla, recuperarla y sustituirla. En cuarto lugar, el control de acceso móvil eliminó la credencial física de la ecuación, y emitir o revocar una credencial en el móvil de alguien resulta más natural desde una plataforma accesible desde cualquier lugar, que es precisamente lo que ya es un servicio alojado.

Preguntas frecuentes sobre ACaaS

¿Qué significa ACaaS?

ACaaS son las siglas en inglés de Access Control as a Service (control de acceso como servicio). Describe un modelo en el que el software que gestiona quién puede abrir cada puerta funciona como una suscripción alojada, mantenida por el proveedor, y en las instalaciones solo se instala el hardware de las puertas.

¿El ACaaS se refiere a las puertas de un edificio o a los sistemas de TI?

En seguridad física, se refiere a puertas, cerraduras y lectores ofrecidos mediante suscripción. En TI, la misma expresión abarca el acceso a archivos, aplicaciones y redes. Ambos ámbitos coinciden en el directorio de identidades: cuando un mismo directorio da servicio a los dos, desactivar una cuenta puede bloquear a la vez el portátil y la puerta principal.

¿En qué se diferencia el ACaaS de un sistema de control de acceso en la nube?

Se trata, en gran medida, de la misma tecnología con un enfoque distinto. «En la nube» describe dónde se ejecuta el software; ACaaS describe cómo se adquiere y quién lo opera. En la práctica, la mayor parte del control de acceso en la nube se vende como servicio, por lo que ambos términos suelen usarse indistintamente.

¿Qué ocurre con las puertas si falla la conexión a internet?

Depende de dónde se tome la decisión de acceso, que es una característica del sistema y no de la nube. En la mayoría de las implantaciones, la decisión se toma en la puerta o en un controlador local a partir de los permisos almacenados, por lo que las personas ya autorizadas siguen pudiendo entrar y los eventos se cargan cuando se recupera la conexión. Lo que no funciona sin conexión es todo aquello que necesita la plataforma en ese momento, como una apertura remota o una credencial validada en el servidor, y cualquier cambio de permisos realizado durante el corte no llegará a la puerta hasta que vuelva a conectarse.

¿Quién es el propietario de los datos de acceso en una implantación de ACaaS?

Según el RGPD, el cliente es el responsable del tratamiento y el proveedor es el encargado del tratamiento, lo que significa que los datos siguen siendo del cliente y que el proveedor solo puede tratarlos en los términos de un acuerdo de tratamiento de datos. Las cuestiones que importan en la práctica son el periodo de conservación, la región de almacenamiento y el formato de exportación, todas ellas incluidas en las preguntas para el proveedor anteriores.

¿Es el ACaaS más barato que un sistema de control de acceso tradicional?

No necesariamente, y conviene ser sinceros al respecto. Empieza con un coste menor, es predecible y elimina por completo los costes de servidores, armarios y actualizaciones. A cinco años, el total puede ser similar. Lo que cambia con seguridad es la forma del gasto, no su cuantía.

Control de acceso como servicio: conclusiones clave

El control de acceso como servicio es un modelo de prestación y comercial, no una nueva tecnología para puertas. Las cerraduras y los lectores son los mismos dispositivos de siempre; lo que cambia de lugar es el software, la administración y la propiedad. El servidor, el armario de controladores, el cableado hasta cada puerta y el proyecto de actualización desaparecen del edificio y se sustituyen por una suscripción y un navegador. Dos preguntas determinan si el modelo encaja en una organización: qué ocurre en la puerta cuando se pierde la conexión, y si la organización puede aceptar que sus datos de acceso los trate un proveedor en virtud de un acuerdo de tratamiento de datos. En la mayoría de los edificios ambas tienen buenas respuestas; en unos pocos, no, y ahí un sistema on-premise sigue siendo la mejor opción. Si ambas respuestas encajan con sus edificios, ATLAS Access Control y sus preguntas frecuentes son un buen siguiente paso.