+55 11 3500-4088
BLOG
Atualização de SO em escala: como o MDM elimina o “nunca atualiza”
Atualização de SO em escala: como o MDM elimina o “nunca atualiza”
Um parque corporativo com versões de Android ou iOS desatualizadas não é apenas um problema de TI. É uma superfície de ataque ativa. O MDM resolve isso sem depender de cada colaborador apertar “atualizar”.
Pergunte para qualquer gestor de TI quantas versões de Android ou iOS existem no parque corporativo da empresa. A resposta, quase sempre, revela um problema que ninguém decidiu ter: dezenas de dispositivos rodando versões antigas de sistema operacional, cada uma com suas próprias vulnerabilidades, incompatibilidades e riscos.
O motivo é simples. Atualizar um sistema operacional depende do colaborador aceitar a notificação. O colaborador não aceita, adia, esquece. Multiplique esse comportamento por 80, 150 ou 400 dispositivos e você tem um parque fragmentado que nenhuma planilha consegue controlar. O MDM foi feito para resolver exatamente isso.
O risco real de um parque desatualizado
Cada versão de sistema operacional desatualizada contém vulnerabilidades conhecidas publicamente, com CVEs (Common Vulnerabilities and Exposures) catalogados. Um dispositivo corporativo rodando Android 11 em 2025 tem acesso à rede da empresa, aos e-mails e aos aplicativos internos com falhas de segurança que a própria fabricante já corrigiu nas versões seguintes. A atualização não é cosmética. É a correção de uma brecha aberta.
Neste artigo
- Por que o parque corporativo acumula versões de SO desatualizadas
- O risco concreto de dispositivos com SO antigo na rede corporativa
- Como o MDM gerencia atualizações de SO sem depender do colaborador
- Android e iOS: como o controle funciona em cada plataforma
- Janela de manutenção: como agendar sem impactar a operação
- Política de atualização de SO: o que configurar no MDM
- Perguntas frequentes
Por que o parque corporativo acumula versões de SO desatualizadas
Não existe uma decisão deliberada de manter os dispositivos desatualizados. O problema é estrutural: as atualizações de sistema operacional em dispositivos corporativos dependem de uma ação do usuário final, que não tem nenhum incentivo técnico imediato para realizá-la.
A notificação aparece. O colaborador está em uma reunião, ou em campo, ou simplesmente não quer reiniciar o dispositivo agora. Adia para depois. Depois não chega. Repete-se o ciclo.
Em um parque de 100 dispositivos, com colaboradores em diferentes locais, regimes de trabalho e níveis de familiaridade com tecnologia, o resultado é sempre o mesmo: uma distribuição caótica de versões de sistema operacional que nenhum gestor controla ativamente.
Sem gestão centralizada
Sem MDM, nenhuma ferramenta enxerga a versão de SO de cada dispositivo em tempo real. O gestor de TI só descobre o problema quando é tarde.
Dependência do colaborador
O modelo tradicional exige que o colaborador aceite e execute a atualização. Em operações distribuídas, isso é incontrolável.
Medo de interrupção
Colaboradores em campo evitam atualizar por receio de reinicialização ou instabilidade durante a jornada. O adiamento vira hábito.
Sem visibilidade do risco
Versões desatualizadas não causam problema visível imediato. O risco é latente e só aparece depois de um incidente de segurança.
O risco concreto de dispositivos com SO antigo na rede corporativa
Versões antigas de Android e iOS não são apenas esteticamente desatualizadas. Cada versão que ficou para trás carrega um conjunto específico de vulnerabilidades documentadas que atacantes podem explorar.
No Android, as atualizações mensais de segurança do Google corrigem dezenas de CVEs a cada ciclo. Um dispositivo que parou de receber essas atualizações, seja por ter um sistema operacional antigo, seja por ser uma marca que não distribui os patches, é tecnicamente vulnerável a ataques que a fabricante já corrigiu.
No iOS, a Apple oferece ciclos de suporte mais longos, mas versões muito antigas deixam de receber correções críticas. Um iPhone corporativo rodando iOS 15 em um ambiente que já está no iOS 18 tem brechas conhecidas sem correção disponível para aquela versão.
O que uma versão desatualizada de Android significa na prática?
Um Android sem o patch de segurança mensal mais recente tem vulnerabilidades conhecidas e publicadas no CVE Database. Essas vulnerabilidades incluem escalação de privilégio, execução remota de código e acesso não autorizado a dados armazenados no dispositivo. O risco não é teórico: existem exploits públicos para a maioria dos CVEs mais antigos, acessíveis a qualquer pessoa com conhecimento básico.
Além do risco de segurança, versões antigas de SO criam incompatibilidades com aplicativos corporativos que exigem versões mínimas de sistema. O resultado é que o colaborador começa a ter problemas de acesso ao ERP, ao e-mail corporativo ou ao app de field service, e o chamado chega para o TI como “o aplicativo não abre”, sem a conexão óbvia com o sistema desatualizado.
Como o MDM gerencia atualizações de SO sem depender do colaborador
A lógica de controle de atualização de SO via MDM inverte o modelo padrão: em vez de notificar o colaborador e esperar sua ação, a plataforma de MDM assume o controle do processo diretamente.
Visibilidade em tempo real da versão de SO
O primeiro passo é saber exatamente qual versão de sistema cada dispositivo está rodando. O MDM mantém um inventário em tempo real com a versão de SO de cada dispositivo gerenciado. O gestor de TI consegue visualizar, em um único painel, quantos dispositivos estão na versão atual, quantos estão atrasados em um patch e quantos estão significativamente desatualizados.
Essa visibilidade por si só já muda a gestão: o problema sai do “acho que alguns dispositivos estão desatualizados” para um número concreto com nomes, departamentos e localização dos equipamentos.
Agendamento silencioso de atualizações
Com o MDM, é possível configurar a instalação automática de atualizações de SO de forma silenciosa, sem que o colaborador precise tomar nenhuma ação. A atualização é baixada, instalada e o dispositivo é reiniciado no horário configurado pelo TI, fora do horário de trabalho.
O colaborador pega o dispositivo na manhã seguinte com o sistema atualizado, sem ter precisado fazer nada e sem que sua jornada tenha sido interrompida.
Forçar versão mínima de SO como requisito de acesso
Uma das configurações mais importantes do MDM para este problema é a política de conformidade baseada em versão de SO. É possível definir que qualquer dispositivo rodando abaixo de uma versão mínima perde acesso ao e-mail corporativo, ao VPN ou a aplicativos internos até que a atualização seja realizada.
Como o MDM força a atualização de SO sem bloquear o colaborador
O MDM não simplesmente bloqueia o dispositivo. A sequência correta é: (1) detectar dispositivo fora de conformidade, (2) notificar o colaborador com prazo, (3) após o prazo, restringir acesso a recursos corporativos até a atualização ser concluída, (4) liberar automaticamente após a atualização. Esse fluxo cria urgência real sem travar a operação imediatamente.
Android e iOS: como o controle funciona em cada plataforma
O nível de controle disponível varia entre Android e iOS, e entender essa diferença é importante para configurar a política corretamente.
Janela de manutenção: como agendar sem impactar a operação
O maior obstáculo prático para implementar atualizações automáticas de SO em dispositivos corporativos é o impacto operacional: a atualização reinicia o dispositivo e pode deixar o colaborador sem acesso por alguns minutos.
O MDM resolve isso com o conceito de janela de manutenção: um intervalo de tempo configurado pelo TI no qual as atualizações são aplicadas automaticamente. O dispositivo é atualizado e reiniciado durante esse período, sem que a jornada de trabalho seja afetada.
Como configurar uma janela de manutenção eficiente
A janela de manutenção ideal tem entre 2 e 4 horas, fora do horário de pico da operação. Para equipes de campo, o intervalo entre 1h e 5h da manhã é o mais comum. Para escritórios, o intervalo entre 22h e 6h funciona bem. O MDM executa o download durante o dia, quando o dispositivo tem Wi-Fi, e reserva a instalação com reinicialização para a janela configurada.
O que acontece com dispositivos que estão em uso fora da janela
Dispositivos que estiverem em uso ativo durante a janela de manutenção podem ter a reinicialização adiada automaticamente. A maioria das plataformas de MDM permite configurar quantas vezes o colaborador pode adiar e por quanto tempo, antes que a atualização se torne obrigatória independente do uso.
Política de atualização de SO: o que configurar no MDM
Uma política de atualização de SO bem estruturada no MDM tem quatro componentes principais:
Inventário de versões atual
Antes de configurar qualquer política, exporte do MDM a distribuição de versões de SO no parque. Esse relatório mostra exatamente o tamanho do problema e quais dispositivos precisam de atenção imediata.
Definição da versão mínima aceita
Estabeleça a versão mínima de SO que o parque deve ter. Para Android, o recomendado é manter no máximo dois patches de segurança de atraso. Para iOS, a versão N-1 (uma versão abaixo da atual) costuma ser o critério padrão de mercado.
Configuração da janela de manutenção
Configure no MDM o intervalo de horário em que as atualizações serão aplicadas automaticamente. Considere os diferentes perfis operacionais da empresa: equipes de campo têm horários diferentes de equipes administrativas.
Política de conformidade com bloqueio de acesso
Ative a política de conformidade que restringe acesso a recursos corporativos para dispositivos fora da versão mínima. Defina um prazo de carência (geralmente 7 a 15 dias) antes do bloqueio entrar em vigor, para dar tempo ao colaborador de realizar a atualização ou acionar o TI.
Relatório de conformidade periódico
Configure alertas automáticos para notificar o TI sempre que um novo dispositivo entrar em não conformidade. O relatório semanal de versões de SO é uma das métricas básicas de saúde do parque corporativo gerenciado por MDM.
Quanto tempo leva para homogeneizar as versões de SO com MDM?
Em parques onde todos os dispositivos têm acesso a Wi-Fi regularmente, é possível homogeneizar as versões de SO em 2 a 4 semanas após a ativação da política de atualização automática. Parques com dispositivos em campo sem acesso frequente a Wi-Fi levam mais tempo, e podem exigir estratégias complementares, como atualização via dados móveis fora de horário de pico.
Importante saber
O MDM controla a instalação de atualizações de SO, mas não cria atualizações onde elas não existem. Se um fabricante de Android descontinuou o suporte para um modelo específico, o MDM não consegue instalar uma versão de SO que o fabricante não disponibilizou. Nesses casos, a solução é identificar o modelo como candidato à substituição no próximo ciclo de renovação do parque.
O MDM consegue adiar uma atualização de SO para testar compatibilidade antes de distribuir?
Sim. Tanto no Android Enterprise quanto no iOS com ABM, o MDM permite adiar a distribuição de uma atualização por até 90 dias após o lançamento oficial. Isso é essencial para empresas com aplicativos críticos: o TI testa a compatibilidade do app corporativo com a nova versão do SO antes de distribuir para todo o parque. A distribuição pode ser feita em fases, começando por um grupo piloto antes do rollout completo.
Perguntas frequentes
O MDM consegue forçar a atualização de SO mesmo se o colaborador recusar a notificação?
Em dispositivos supervisionados (Android Enterprise com perfil totalmente gerenciado, ou iOS supervisionado via ABM), sim. A instalação ocorre silenciosamente durante a janela de manutenção, sem que o colaborador possa recusar. Em dispositivos com perfil de trabalho pessoal (BYOD), o controle é mais limitado e pode exigir a conformidade como condição para acesso a recursos corporativos.
A atualização de SO forçada pelo MDM pode causar problemas nos aplicativos corporativos?
Pode, se não houver um processo de teste prévio. Por isso a funcionalidade de adiamento de até 90 dias existe: ela permite que o TI valide a compatibilidade dos aplicativos críticos com a nova versão do SO antes de distribuir para todo o parque. Ignorar esse teste e aplicar diretamente pode gerar incompatibilidades em apps de campo, ERPs e ferramentas corporativas.
Como o MDM se comporta com dispositivos que não têm acesso à internet durante a janela de manutenção?
O dispositivo tenta baixar e instalar a atualização na próxima vez que tiver conexão disponível após a janela de manutenção. A plataforma de MDM rastreia quais dispositivos concluíram a atualização e quais ainda estão pendentes, permitindo ao TI identificar os casos que precisam de atenção especial, como dispositivos permanentemente offline.
O controle de atualização de SO funciona para tablets e coletores de dados, além de smartphones?
Sim, para qualquer dispositivo Android ou iOS gerenciado pelo MDM, independente do tipo de hardware. Tablets, coletores de dados industriais com Android e dispositivos dedicados seguem as mesmas políticas de atualização configuradas para os smartphones da empresa.
Quer saber quantas versões de SO diferentes existem no seu parque?
A MOBIT faz o diagnóstico do seu parque de dispositivos corporativos, mapeia as versões de SO em uso e estrutura a política de atualização via MDM para o seu ambiente.
Conteúdos relacionados
Continue lendo sobre MDM Corporativo
Política de dispositivos
BYOD vs. COPE vs. COBO: qual política escolher para sua empresa
Custo e ROI
Quanto custa MDM: estrutura de custo real, modelos de licenciamento e como calcular o ROI
Android corporativo
MDM Android corporativo: como funciona o Android Enterprise e como gerenciar sua base de celulares Android
Deixe um comentário