Amazon MSK Express brokers now delivers data to Amazon S3 general purpose buckets, providing a fully managed capability to deliver Apache Kafka data in Amazon S3 for downstream processing in the easiest and most reliable way. This capability automatically scales to deliver high-throughput Kafka data to S3 with end-to-end reliability for mission-critical workloads, while reducing ingestion and delivery costs by up to 60% compared to self-managed alternatives.
Customers deliver Apache Kafka data to Amazon S3 for use cases such as log archival, compliance retention, Kafka replay, and training AI/ML models, and typically build these pipelines with self-managed connectors that grow costly and operationally complex as workloads scale, forcing teams to build or source S3 connector plugins, secure approvals to deploy them, and continually scale capacity, and apply security updates across connector fleet. With this capability, MSK Express automatically handles scaling, retries, and backpressure so customers no longer manage connector fleets or coordinate across teams. MSK Express supports throughput of up to 10 GB/s for data delivery to Amazon S3, and manages routine operations such as capacity scaling and version upgrades without introducing delivery gaps. Additionally, customers add this delivery capability without provisioning additional broker egress throughput, which eliminates the incremental infrastructure costs that scaling connector-based pipelines typically incurs, so customers scale delivery to actual workload demand rather than provisioning for peak, achieving reliable, high-throughput delivery to Amazon S3 while removing operational overhead and lowering costs.
Amazon MSK Express brokers now delivers data to Amazon S3 general purpose buckets, providing a fully managed capability to deliver Apache Kafka data in Amazon S3 for downstream processing in the easiest and most reliable way. This capability automatically scales to deliver high-throughput Kafka data to S3 with end-to-end reliability for mission-critical workloads, while reducing ingestion and delivery costs by up to 60% compared to self-managed alternatives.
Customers deliver Apache Kafka data to Amazon S3 for use cases such as log archival, compliance retention, Kafka replay, and training AI/ML models, and typically build these pipelines with self-managed connectors that grow costly and operationally complex as workloads scale, forcing teams to build or source S3 connector plugins, secure approvals to deploy them, and continually scale capacity, and apply security updates across connector fleet. With this capability, MSK Express automatically handles scaling, retries, and backpressure so customers no longer manage connector fleets or coordinate across teams. MSK Express supports throughput of up to 10 GB/s for data delivery to Amazon S3, and manages routine operations such as capacity scaling and version upgrades without introducing delivery gaps. Additionally, customers add this delivery capability without provisioning additional broker egress throughput, which eliminates the incremental infrastructure costs that scaling connector-based pipelines typically incurs, so customers scale delivery to actual workload demand rather than provisioning for peak, achieving reliable, high-throughput delivery to Amazon S3 while removing operational overhead and lowering costs.
Amazon MSK data delivery to Amazon S3 is available today in every AWS Region where Amazon MSK Express brokers are offered. For pricing information, visit the pricing page. To learn more, visit the Amazon MSK Developer Guide and Amazon MSK AI skills.
The Gemma 4 family of open-weight models from Google DeepMind on Amazon Bedrock in AWS GovCloud (US-West). With Gemma 4, you can build generative AI applications across reasoning, multimodal understanding, agentic, and software engineering workflows.
The Gemma 4 family on Amazon Bedrock includes three variants – Gemma 4 31B, Gemma 4 26B-A4B, and Gemma 4 E2B – spanning dense and mixture-of-experts (MoE) architectures with built-in reasoning, native function calling, support for 35+ languages and multimodal input across text, image, video and audio. Gemma 4 31B is suited for reasoning- and coding-heavy workloads with a 256K-token context window, Gemma 4 26B-A4B targets cost- and latency-sensitive workloads, and Gemma 4 E2B is the smallest variant, designed for low-latency interactive use cases. Gemma 4 runs on a new innovation in Amazon Bedrock designed for price performance, with improved support for tool calling, structured output, reasoning, and response streaming, so customers can build reliable generative AI applications with open-source models.
To get started, visit Gemma 4 model detail pages in our documentation.
The Gemma 4 family of open-weight models from Google DeepMind on Amazon Bedrock in AWS GovCloud (US-West). With Gemma 4, you can build generative AI applications across reasoning, multimodal understanding, agentic, and software engineering workflows.
The Gemma 4 family on Amazon Bedrock includes three variants – Gemma 4 31B, Gemma 4 26B-A4B, and Gemma 4 E2B – spanning dense and mixture-of-experts (MoE) architectures with built-in reasoning, native function calling, support for 35+ languages and multimodal input across text, image, video and audio. Gemma 4 31B is suited for reasoning- and coding-heavy workloads with a 256K-token context window, Gemma 4 26B-A4B targets cost- and latency-sensitive workloads, and Gemma 4 E2B is the smallest variant, designed for low-latency interactive use cases. Gemma 4 runs on a new innovation in Amazon Bedrock designed for price performance, with improved support for tool calling, structured output, reasoning, and response streaming, so customers can build reliable generative AI applications with open-source models.
To get started, visit Gemma 4 model detail pages in our documentation.
You can now run OpenSearch version 3.7 on Amazon OpenSearch Service. OpenSearch 3.7 introduces improvements in vector search performance, search relevance, and Query Insights.
With this launch, 1-bit scalar quantization on the Faiss and Lucene engines compresses vectors, reducing the storage and memory required by vector workloads while maintaining search accuracy. You can now retrieve vectors faster using doc values instead of document source, with no reindexing required. Search Relevance Workbench adds new evaluation metrics, CSV judgment uploads, and expanded hybrid search optimization, helping you measure and improve search quality.
This launch also introduces new Query Insights capabilities, including automated query recommendations, a finished-queries cache for observing recently completed queries, and the option to export top query data to Amazon S3, helping you identify expensive queries and analyze trends over time.
For information on upgrading to OpenSearch 3.7, please see the documentation. OpenSearch 3.7 is now available in all AWS Regions where Amazon OpenSearch Service is available.
You can now run OpenSearch version 3.7 on Amazon OpenSearch Service. OpenSearch 3.7 introduces improvements in vector search performance, search relevance, and Query Insights.
With this launch, 1-bit scalar quantization on the Faiss and Lucene engines compresses vectors, reducing the storage and memory required by vector workloads while maintaining search accuracy. You can now retrieve vectors faster using doc values instead of document source, with no reindexing required. Search Relevance Workbench adds new evaluation metrics, CSV judgment uploads, and expanded hybrid search optimization, helping you measure and improve search quality.
This launch also introduces new Query Insights capabilities, including automated query recommendations, a finished-queries cache for observing recently completed queries, and the option to export top query data to Amazon S3, helping you identify expensive queries and analyze trends over time.
For information on upgrading to OpenSearch 3.7, please see the documentation. OpenSearch 3.7 is now available in all AWS Regions where Amazon OpenSearch Service is available.
AWS Glue now supports VPC connections, filter pushdown, and partition support for the REST API connector. The REST API connector enables you to ingest data from any source that exposes a REST-based API, including proprietary systems and emerging platforms without native AWS Glue connectors. With this launch, you can operate your ETL pipelines from data sources with REST API endpoints by securely connecting to private endpoints, transfering only the data they need, and parallelizing reads for faster ingestion, all without writing custom code
With VPC support, you can use the REST API connector to access data sources hosted in private subnets or connected through VPNs or AWS PrivateLink, without exposing traffic to the public internet. Filter pushdown translates your query predicates into API-native parameters, so only matching records leave the source, reducing data transfer costs and improving job performance. Partition support splits large datasets across multiple Spark workers using field-based or record-count strategies, providing parallel reads that reduce ingestion time for high-volume, paginated APIs.
These capabilities are available in all AWS commercial regions where AWS Glue is available.
AWS Glue now supports VPC connections, filter pushdown, and partition support for the REST API connector. The REST API connector enables you to ingest data from any source that exposes a REST-based API, including proprietary systems and emerging platforms without native AWS Glue connectors. With this launch, you can operate your ETL pipelines from data sources with REST API endpoints by securely connecting to private endpoints, transfering only the data they need, and parallelizing reads for faster ingestion, all without writing custom code With VPC support, you can use the REST API connector to access data sources hosted in private subnets or connected through VPNs or AWS PrivateLink, without exposing traffic to the public internet. Filter pushdown translates your query predicates into API-native parameters, so only matching records leave the source, reducing data transfer costs and improving job performance. Partition support splits large datasets across multiple Spark workers using field-based or record-count strategies, providing parallel reads that reduce ingestion time for high-volume, paginated APIs. These capabilities are available in all AWS commercial regions where AWS Glue is available. To get started, visit the AWS Glue REST API connector documentation.
Amazon EC2 Auto Scaling now supports Instance Refresh as a new AWS CloudFormation update policy. When you configure the new AutoScalingInstanceRefresh update policy and update properties that require instance replacement, CloudFormation automatically triggers an Instance Refresh.
With this integration, you can now access Instance Refresh capabilities including replace root volume for in-place updates, launch-before-terminate, alarm-based monitoring, and checkpoints with bake time for controlled rollouts. Auto Scaling features such as scaling policies and health checks remain active throughout the update, so your service health is not at risk during deployments. Rollback is handled through CloudFormation stack rollback.
This feature is available in all AWS Regions at no additional cost. To learn more, see AutoScalingInstanceRefresh update policy in the AWS CloudFormation Template Reference.
Amazon EC2 Auto Scaling now supports Instance Refresh as a new AWS CloudFormation update policy. When you configure the new AutoScalingInstanceRefresh update policy and update properties that require instance replacement, CloudFormation automatically triggers an Instance Refresh.
With this integration, you can now access Instance Refresh capabilities including replace root volume for in-place updates, launch-before-terminate, alarm-based monitoring, and checkpoints with bake time for controlled rollouts. Auto Scaling features such as scaling policies and health checks remain active throughout the update, so your service health is not at risk during deployments. Rollback is handled through CloudFormation stack rollback.
This feature is available in all AWS Regions at no additional cost. To learn more, see AutoScalingInstanceRefresh update policy in the AWS CloudFormation Template Reference.
Today, AWS WAF adds pre-parse text transformations for query arguments and ten new text transformations for use in any rule statement. Both help you normalize request content so that AWS WAF inspects requests the same way your application interprets them.
Pre-parse text transformations normalize a raw query string before AWS WAF parses it into key-value pairs, closing HTTP parameter pollution and parser differential evasion gaps. You can chain up to ten transformations, including URL decode, Combine Duplicate Query Arguments by Comma, and Replace Semicolons with Ampersands, then layer standard post-parse transformations on top within a single rule statement.
The new text transformations give you more ways to normalize content before inspection, including industry-standard options such as Uppercase, Trim, Remove Whitespace, and SHA256, plus operating-system-aware command line and JavaScript decoding functions developed by the Amazon Threat Research Team.
Each new transformation consumes 10 WCUs, with no additional charge beyond standard AWS WAF pricing, and is available in all AWS Regions. To get started, see the following resources:
Today, AWS WAF adds pre-parse text transformations for query arguments and ten new text transformations for use in any rule statement. Both help you normalize request content so that AWS WAF inspects requests the same way your application interprets them.
Pre-parse text transformations normalize a raw query string before AWS WAF parses it into key-value pairs, closing HTTP parameter pollution and parser differential evasion gaps. You can chain up to ten transformations, including URL decode, Combine Duplicate Query Arguments by Comma, and Replace Semicolons with Ampersands, then layer standard post-parse transformations on top within a single rule statement.
The new text transformations give you more ways to normalize content before inspection, including industry-standard options such as Uppercase, Trim, Remove Whitespace, and SHA256, plus operating-system-aware command line and JavaScript decoding functions developed by the Amazon Threat Research Team.
Each new transformation consumes 10 WCUs, with no additional charge beyond standard AWS WAF pricing, and is available in all AWS Regions. To get started, see the following resources:
Pre-parse text transformations in AWS WAF: https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-preparse-transformation.html
Text transformations in AWS WAF: https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-transformation.html
Getting started with AWS WAF: https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html
Amazon Redshift Data API introduces new capabilities that reduce the number of API calls to retrieve SQL statement metadata or results, provide visibility into sessions, and allow batch statements to execute on separate transactions.
Long polling: Long polling enables you to retrieve SQL statement metadata or results without polling repeatedly until the SQL statement reaches a terminal state, by delaying returning a synchronous response until the SQL statement finishes. To use this feature, specify the WaitTimeSeconds parameter on ExecuteStatement, BatchExecuteStatement, DescribeStatement, GetStatementResult, or GetStatementResultV2.
ListSessions: Applications that reuse sessions across multiple queries can now enumerate active sessions and filter by status, compute target, or database, eliminating the need to track session identifiers externally.
Flexible batch execution: BatchExecuteStatement now supports an ExecutionMode parameter with AUTO_COMMIT mode, allowing each SQL statement in a batch to execute independently so a single failure no longer rolls back the entire batch — useful for ETL pipelines and administrative scripts where partial completion is acceptable. In addition, BatchExecuteStatement now accepts an array of SqlParameter, enabling parameter reuse across all statements in a batch: define parameters once and reference them in any statement, eliminating the need to embed literal values in each query.
These features are generally available for Amazon Redshift Provisioned and Amazon Redshift Serverless in all AWS commercial and AWS GovCloud (US) Regions that support Amazon Redshift Data API. To get started, visit the Amazon Redshift Data API developer guide.
Amazon Redshift Data API introduces new capabilities that reduce the number of API calls to retrieve SQL statement metadata or results, provide visibility into sessions, and allow batch statements to execute on separate transactions. Long polling: Long polling enables you to retrieve SQL statement metadata or results without polling repeatedly until the SQL statement reaches a terminal state, by delaying returning a synchronous response until the SQL statement finishes. To use this feature, specify the WaitTimeSeconds parameter on ExecuteStatement, BatchExecuteStatement, DescribeStatement, GetStatementResult, or GetStatementResultV2. ListSessions: Applications that reuse sessions across multiple queries can now enumerate active sessions and filter by status, compute target, or database, eliminating the need to track session identifiers externally. Flexible batch execution: BatchExecuteStatement now supports an ExecutionMode parameter with AUTO_COMMIT mode, allowing each SQL statement in a batch to execute independently so a single failure no longer rolls back the entire batch — useful for ETL pipelines and administrative scripts where partial completion is acceptable. In addition, BatchExecuteStatement now accepts an array of SqlParameter, enabling parameter reuse across all statements in a batch: define parameters once and reference them in any statement, eliminating the need to embed literal values in each query. These features are generally available for Amazon Redshift Provisioned and Amazon Redshift Serverless in all AWS commercial and AWS GovCloud (US) Regions that support Amazon Redshift Data API. To get started, visit the Amazon Redshift Data API developer guide.
AWS announces the general availability (GA) of AWS Interconnect — multicloud with Oracle Cloud Infrastructure (OCI).
Customers have been adopting multicloud strategies while migrating more applications to the cloud. They do so for many reasons including interoperability requirements, the freedom to choose technology that best suits their needs, and the ability to build and deploy applications on any environment with greater ease and speed. Previously, when interconnecting workloads across multiple cloud providers (CSPs), customers had to go the route of a ‘do-it-yourself’ multicloud approach, leading to complexities of building and managing global multi-layered networks at scale. AWS Interconnect – multicloud is the first purpose-built product of its kind and a new way of how clouds connect and talk to each other, allowing customers to quickly provision resilient, scalable private connections to other cloud providers.
In May, OCI launched support for AWS Interconnect in public preview and became the latest CSP to adopt the open specification that powers the service. With today’s GA launch, AWS customers can now rely on the same consistent, simple experience to interconnect their workloads on OCI and Google Cloud. Microsoft Azure will launch later in 2026.
Interconnect – multicloud is available with OCI in the us-east-1 (N. Virginia) AWS Region. You can create an Interconnect using the AWS Management Console, Command Line Interface (CLI), or API. For more information, see the AWS Interconnect – multicloud documentation.
AWS announces the general availability (GA) of AWS Interconnect — multicloud with Oracle Cloud Infrastructure (OCI).
Customers have been adopting multicloud strategies while migrating more applications to the cloud. They do so for many reasons including interoperability requirements, the freedom to choose technology that best suits their needs, and the ability to build and deploy applications on any environment with greater ease and speed. Previously, when interconnecting workloads across multiple cloud providers (CSPs), customers had to go the route of a ‘do-it-yourself’ multicloud approach, leading to complexities of building and managing global multi-layered networks at scale. AWS Interconnect – multicloud is the first purpose-built product of its kind and a new way of how clouds connect and talk to each other, allowing customers to quickly provision resilient, scalable private connections to other cloud providers.
In May, OCI launched support for AWS Interconnect in public preview and became the latest CSP to adopt the open specification that powers the service. With today’s GA launch, AWS customers can now rely on the same consistent, simple experience to interconnect their workloads on OCI and Google Cloud. Microsoft Azure will launch later in 2026. Interconnect – multicloud is available with OCI in the us-east-1 (N. Virginia) AWS Region. You can create an Interconnect using the AWS Management Console, Command Line Interface (CLI), or API. For more information, see the AWS Interconnect – multicloud documentation.
IAM Identity Center helps you configure the single sign-on experience of your workforce to AWS accounts and applications. You can now replicate IAM Identity Center from the primary AWS Region where you first enabled it to additional Regions of your choice when using Identity Center directory as your identity source. This extends the multi-Region support capability, previously available for Identity Center organization instances connected to external identity providers, to instances that use the Identity Center directory to manage and authenticate their workforce. This feature enhances resilience of user access to AWS accounts and helps you deploy AWS applications in the AWS Regions that best align with your business needs such as application data residency and proximity to users.
When you enable this feature, IAM Identity Center automatically replicates your identities, entitlements, and other information from the primary Region to additional Regions. If IAM Identity Center is affected by a disruption in the primary Region, IAM Identity Center users continue to have access to their AWS accounts using the already provisioned entitlements in the additional Regions.
AWS application administrators can use the standard application deployment workflow to deploy their application in an additional Region while you continue to administer IAM Identity Center in the primary Region.
IAM Identity Center helps you configure the single sign-on experience of your workforce to AWS accounts and applications. You can now replicate IAM Identity Center from the primary AWS Region where you first enabled it to additional Regions of your choice when using Identity Center directory as your identity source. This extends the multi-Region support capability, previously available for Identity Center organization instances connected to external identity providers, to instances that use the Identity Center directory to manage and authenticate their workforce. This feature enhances resilience of user access to AWS accounts and helps you deploy AWS applications in the AWS Regions that best align with your business needs such as application data residency and proximity to users.
When you enable this feature, IAM Identity Center automatically replicates your identities, entitlements, and other information from the primary Region to additional Regions. If IAM Identity Center is affected by a disruption in the primary Region, IAM Identity Center users continue to have access to their AWS accounts using the already provisioned entitlements in the additional Regions.
AWS application administrators can use the standard application deployment workflow to deploy their application in an additional Region while you continue to administer IAM Identity Center in the primary Region.
IAM Identity Center multi-Region support is currently available in the 17 enabled-by-default commercial AWS Regions for organization instances of IAM Identity Center. The IAM Identity Center organization instance must be configured with a multi-Region customer managed KMS key (CMK). To find out which AWS applications support deployment in additional Regions, visit AWS applications that you can use with IAM Identity Center. Standard AWS KMS charges apply for storing and using CMKs. IAM Identity Center is provided at no additional cost. To learn more about IAM Identity Center, visit the product detail page. To get started, see the IAM Identity Center User Guide.
Las claves de acceso son el método de autenticación predeterminado en Entra ID
Por: Nadim Abdo, vicepresidente corporativo de Identidad e Ingeniería de Acceso a Redes, Microsoft.
A medida que los ataques de identidad se vuelven más sofisticados en la era de la IA, las organizaciones necesitan métodos de autenticación más sólidos que protejan a los usuarios del phishing, el robo de credenciales y la ingeniería social. Para hacer frente a estas amenazas en evolución, Microsoft Entra ID actualiza su experiencia de autenticación al hacer que las claves de acceso sean el método de autenticación predeterminado y resistente al phishing, para ayudar a los clientes a reducir la dependencia de métodos que sean susceptibles a phishing, como SMS y voz.
A partir del 1 de septiembre de 2026, Microsoft comenzará a desplegar las claves de acceso como la experiencia de autenticación predeterminada en Microsoft Entra ID. A medida que el despliegue llega a cada organización, los usuarios habilitados para la autenticación por SMS o voz se habilitarán en automático para las claves de acceso, y la próxima vez que realicen autenticación multifactor, se les pedirá que registren una clave.
Tras esta transición, el 1 de febrero de 2027, Microsoft retirará la entrega de telecomunicaciones proporcionada por Microsoft para la autenticación por SMS y voz y dejará de ofrecer SMS y voz como una capacidad nativa de Microsoft Entra. Las organizaciones que aún requieran métodos de autenticación por SMS o voz tendrán la opción de elegir uno de nuestros socios de telecomunicaciones a través de la Microsoft Security Store. Los clientes serán responsables de cualquier coste relacionado con las telecomunicaciones que cobren los socios de telecomunicaciones.
Recomendamos que los usuarios pasen a las claves de acceso u otro método de autenticación resistente al phishing lo antes posible.
Por qué es importante una autenticación más fuerte en la era de la IA
Los métodos de autenticación que utilizan SMS o voz dependen de secretos compartidos o canales que los atacantes interceptan, manipulan o hacen phishing cada vez más. Las claves de acceso utilizan criptografía de clave pública en lugar de secretos compartidos, lo que las hace resistentes al phishing por diseño. También ofrecen una experiencia de inicio de sesión más rápida y sencilla para los usuarios.
El argumento para ir más allá de los SMS y la voz ya no es solo que los atacantes intercepten o manipulen a nivel social estos métodos. El entorno de amenazas ha cambiado en velocidad, escala y sofisticación. Microsoft Threat Intelligence ha observado que campañas de phishing habilitadas por IA alcanzan tasas de clics de hasta el 54%, frente a cerca del 12% de campañas más tradicionales, lo que convierte en un riesgo urgente que las contraseñas robadas y los segundos factores que se pueden hacer phishing.1 Al mismo tiempo, tácticas como el intercambio de SIM y el bypass de autenticación multifactor se han vuelto más accesibles y repetibles.
Un ciberataque impulsado por IA puede utilizar una identidad comprometida para automatizar el descubrimiento, la escalada de privilegios y el movimiento lateral mucho más rápido que un atacante humano que trabaja de manera manual. Por eso los métodos de autenticación resistentes al phishing son tan importantes.
Al convertir las claves de acceso en la experiencia predeterminada de autenticación, las organizaciones reducen la dependencia de métodos de autenticación phishing y refuerzan la protección contra el robo de credenciales y el phishing.
¿Aun necesitan SMS o voz? Seleccionen un proveedor de telecomunicaciones en Microsoft Security Store
Hoy en día, Microsoft proporciona la entrega de telecomunicaciones mediante SMS y autenticación por voz de manera nativa dentro de Entra ID. Como parte de esta transición, dejaremos de ofrecer esa entrega nativa de telecomunicaciones para fomentar métodos resistentes al phishing como estándar para todos.
Para la mayoría de las organizaciones, el camino recomendado es sencillo: mover a los usuarios a claves de acceso sin coste adicional.
Si tienen un requisito regulatorio, técnico o empresarial para mantener SMS o voz, podrán seleccionar, configurar y gestionar un proveedor de telecomunicaciones externo a través de Microsoft Security Store, un marketplace de socios donde pueden contratar de manera directa con operadores compatibles.
El 18 de septiembre de 2026, compartiremos información sobre proveedores compatibles, orientación de despliegue y documentación técnica, con precios y condiciones comerciales disponibles a través de la Microsoft Security Store.
Cómo prepararse
Empiecen a planificar su transición ahora para que puedan elegir el enfoque de despliegue que mejor se adapte a su organización y asegurarse de que sus usuarios estén preparados para los próximos cambios en su experiencia de inicio de sesión.
Identifiquen a los usuarios que aún usan SMS o voz. Revisen su política de métodos de autenticación e identifica qué usuarios o grupos están habilitados para la autenticación por SMS o voz.
Planifiquen el despliegue de la clave de acceso. Activen las claves de acceso y seleccionen los tipos que mejor se adapten a los dispositivos y flujos de trabajo de sus usuarios. Microsoft Entra ID soporta:
Claves de acceso sincronizadas, como las que se almacenan en gestores de credenciales de plataforma como iCloud Keychain y Google Password Manager.
Claves de acceso vinculadas al dispositivo, como las claves de Microsoft Authenticator, la clave de acceso Entra en Windows y las claves de seguridad FIDO2.
Utilicen una campaña de registro para impulsar la adopción. Microsoft Entra ID puede ayudar a las organizaciones a mover a los usuarios a gran escala, solicitándoles que registren una clave de acceso durante el inicio de sesión de autenticación multifactor.
Preparen las comunicaciones con los usuarios. Informen a los usuarios afectados qué cambia, cuándo verán un mensaje de registro de la clave de acceso y cómo completar el registro en su dispositivo.
Para orientación paso a paso sobre cómo planificar, desplegar y gestionar las claves de acceso, consulten nuestra documentación de Microsoft Learn y la guía de despliegue de claves de acceso.
Si los escenarios regulados, técnicos u operativos aún requieren SMS o voz:
Identifiquen y documenten los segmentos de usuarios afectados.
A partir del 30 de octubre de 2026, seleccionen y configuren un proveedor de telecomunicaciones compatible a través de la Microsoft Security Store.
Prueben su configuración con un grupo de pilotos antes de cualquier despliegue general.
Cronología
Fecha
Hito
1 de septiembre de 2026
Todos los usuarios habilitados para SMS o voz están habilitados en automático y se les permite el registro de la clave de acceso tras iniciar sesión en la autenticación multifactor.
Utilicen la guía de implementación de la clave de acceso para preparar su entorno para el uso de la clave. Notifiquen a los usuarios afectados sobre el cambio que se avecina. Asegúrense de que cada usuario tenga un método de autenticación resistente al phishing, como una clave de acceso, claves de acceso Entra en Windows o una clave de seguridad FIDO2.
18 de septiembre de 2026
Se compartirán precios, condiciones comerciales y una lista de proveedores de telecomunicaciones compatibles.
Si planean continuar con la autenticación por SMS o voz, revisen las opciones de proveedores disponibles e identifica a los usuarios afectados.
30 de octubre de 2026
Los administradores pueden seleccionar y configurar un proveedor de telecomunicaciones compatible a través de la Microsoft Security Store.
1 de febrero de 2027
Finalicen la autenticación por SMS y voz proporcionada por Microsoft.
Si el SMS o la voz siguen aún son necesarios para usuarios específicos, configuren un proveedor de telecomunicaciones compatible antes de esa fecha.
Después del 1 de febrero de 2027
Los usuarios que utilicen SMS o voz para la autenticación multifactor deberán registrar una clave de acceso antes de poder iniciar sesión. Se aplicarán avisos automáticos para registrar una clave de acceso para todos los usuarios en todos los inquilinos. No habrá opción de optar por no participar.
Nota: Las fechas indicadas en esta publicación se aplican sólo a Microsoft Entra ID en la nube pública. El soporte para otros entornos de nube seguirá en un calendario separado, con directrices y fechas adicionales que se anunciarán con antelación.
Los SMS y la voz han cumplido bien su función, para llevar la autenticación multifactor a miles de millones de usuarios que de otro modo no tendrían ninguna. Pero el entorno de amenazas ha evolucionado más allá de sus capacidades, y necesitamos evolucionar con él.
Hacemos que las claves de acceso sean las predeterminadas en el ID de Entra porque funcionan mejor para los usuarios y peor para los ciberatacantes. Intentamos que esta transición sea lo más predecible posible con fechas claras, opciones de respaldo durante la migración y una recuperación que ya no dependa de credenciales de phishing.
Para saber más sobre las soluciones de seguridad de Microsoft, visiten nuestra página web. Agreguen a Favoritos el blog de Seguridad para estar al día con nuestra cobertura experta sobre temas de seguridad. Además, síganos en LinkedIn (Microsoft Security) y X (@MSFTSecurity) para las últimas noticias y actualizaciones sobre ciberseguridad.
