Normal view

Happy 9th Anniversary, CTA: A Celebration of Collaboration in Cyber Defense

24 January 2026 at 01:00

Unit 42 celebrates 9 years of the Cyber Threat Alliance, tracing its journey from a bold idea to a global leader in collaborative cyber defense.

The post Happy 9th Anniversary, CTA: A Celebration of Collaboration in Cyber Defense appeared first on Unit 42.

Updated PCI PIN compliance package for AWS Payment Cryptography now available

24 January 2026 at 00:14

Amazon Web Services (AWS) is pleased to announce the successful completion of Payment Card Industry Personal Identification Number (PCI PIN) audit for the AWS Payment Cryptography service.

With AWS Payment Cryptography, your payment processing applications can use payment hardware security modules (HSMs) that are PCI PIN Transaction Security (PTS) HSM certified and fully managed by AWS, with PCI PIN-compliant key management. This attestation gives you the flexibility to deploy your regulated workloads with reduced compliance overhead.

The PCI PIN compliance report package for AWS Payment Cryptography includes two key components:

  • PCI PIN Attestation of Compliance (AOC) – demonstrating that AWS Payment Cryptography was successfully validated against the PCI PIN standard with zero findings
  • PCI PIN Responsibility Summary – provides guidance to help AWS customers understand their responsibilities in developing and operating a highly secure environment for handling PIN-based transactions

AWS was evaluated by Coalfire, a third-party Qualified Security Assessor (QSA). Customers can access the PCI PIN Attestation of Compliance (AOC) and PCI PIN Responsibility Summary reports through AWS Artifact.

To learn more about our PCI programs and other compliance and security programs, visit the AWS Compliance Programs page. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Compliance Support page.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Tushar Jain

Tushar Jain

Tushar is a Compliance Program Manager at AWS. He leads multiple security and privacy initiatives within AWS. Tushar holds a Master of Business Administration from Indian Institute of Management Shillong, India and a Bachelor of Technology in electronics and telecommunication engineering from Marathwada University, India. He has over 13 years of experience in information security and holds CCSK and CSXF certifications.

Will Black

Will Black

Will is a Compliance Program Manager at Amazon Web Services. He leads multiple security and compliance initiatives within AWS. He has ten years of experience in compliance and security assurance and holds a degree in Management Information Systems from Temple University. Additionally, he holds the CCSK and ISO 27001 Lead Implementer certifications.

AWS achieves 2025 C5 Type 2 attestation report with 183 services in scope 

23 January 2026 at 22:39

Amazon Web Services (AWS) is pleased to announce a successful completion of the 2025 Cloud Computing Compliance Criteria Catalogue (C5) attestation cycle with 183 services in scope. This alignment with C5 requirements demonstrates our ongoing commitment to adhere to the heightened expectations for cloud service providers. AWS customers in Germany and across Europe can run their applications in the AWS Regions that are in scope of the C5 report with the assurance that AWS aligns with C5 criteria.

The C5 attestation scheme is backed by the German government and was introduced by the Federal Office for Information Security (BSI) in 2016. AWS has adhered to the C5 requirements since their inception. C5 helps organizations demonstrate operational security against common cybersecurity threats when using cloud services.

Independent third-party auditors evaluated AWS for the period of October 1, 2024, through September 30, 2025. The C5 report illustrates the compliance status of AWS for both the basic and additional criteria of C5. Customers can download the C5 report through AWS Artifact, a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console or learn more at Getting Started with AWS Artifact.

AWS has added the following five services to the current C5 scope:

The following AWS Regions are in scope of the 2025 C5 attestation: Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Milan), Europe (Paris), Europe (Stockholm), Europe (Spain), Europe (Zurich), and Asia Pacific (Singapore). For up-to-date information, see the C5 page of our AWS Services in Scope by Compliance Program.

Security and compliance is a shared responsibility between AWS and the customer. When customers move their computer systems and data to the cloud, security responsibilities are shared between the customer and the cloud service provider. For more information, see the AWS Shared Security Responsibility Model.

To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

Reach out to your AWS account team if you have questions or feedback about the C5 report.
If you have feedback about this post, submit comments in the Comments section below.

Tea Jioshvili

Tea Jioshvili

Tea is a Manager in AWS Compliance & Security Assurance based in Berlin, Germany. She leads various third-party audit programs across Europe. She previously worked in security assurance and compliance, business continuity, and operational risk management in the financial industry for 20 years.

From runtime risk to real‑time defense: Securing AI agents 

AI agents, whether developed in Microsoft Copilot Studio or on alternative platforms, are becoming a powerful means for organizations to create custom solutions designed to enhance productivity and automate organizational processes by seamlessly integrating with internal data and systems. 

From a security research perspective, this shift introduces a fundamental change in the threat landscape. As Microsoft Defender researchers evaluate how agents behave under adversarial pressure, one risk stands out: once deployed, agents can access sensitive data and execute privileged actions based on natural language input alone. If an threat actor can influence how an agent plans or sequences those actions, the result may be unintended behavior that operates entirely within the agent’s allowed permissions, which makes it difficult to detect using traditional controls. 

To address this, it is important to have a mechanism for verifying and controlling agent behavior during runtime, not just at build time. 

By inspecting agent behavior as it executes, defenders can evaluate whether individual actions align with intended use and policy. In Microsoft Copilot Studio, this is supported through real-time protection during tool invocation, where Microsoft Defender performs security checks that determine whether each action should be allowed or blocked before execution. This approach provides security teams with runtime oversight into agent behavior while preserving the flexibility that makes agents valuable. 

In this article, we examine three scenarios inspired by observed and emerging AI attack techniques, where threat actors attempt to manipulate agent tool invocation to produce unsafe outcomes, often without the agent creator’s awareness. For each scenario, we show how webhook-based runtime checks, implemented through Defender integration with Copilot Studio, can detect and stop these risky actions in real time, giving security teams the observability and control needed to deploy agents with confidence. 

Topics, tools, and knowledge sources:  How AI agents execute actions and why attackers target them 

Figure 1: A visual representation of the 3 elements Copilot Studio agents relies on to respond to user prompts.

Microsoft Copilot Studio agents are composed of multiple components that work together to interpret input, plan actions, and execute tasks. From a security perspective, these same components (topics, tools, and knowledge sources) also define the agent’s effective attack surface. Understanding how they interact is essential to recognizing how attackers may attempt to influence agent behavior, particularly in environments that rely on generative orchestration to chain actions at runtime. Because these components determine how the agent responds to user prompts and autonomous triggers, crafted input becomes a primary vector for steering the agent toward unintended or unsafe execution paths. 

When using generative orchestration, each user input or trigger can cause the orchestrator to dynamically build and execute a multi-step plan, leveraging all three components to deliver accurate and context-aware results. 

  1. Topics are modular conversation flows triggered by specific user phrases. Each topic is made up of nodes that guide the conversation step-by-step, and can include actions, questions, or conditions. 
  1. Tools are the capabilities the copilot can call during a conversation, such as connector actions, AI builder models, or generative answers. These can be embedded within topics or executed independently, giving the agent flexibility in how it handles requests. 
  1. Knowledge sources enhance generative answers by grounding them in reliable enterprise content. When configured, they allow the copilot to access information from Power Platform, Dynamics 365, websites, and other external systems, ensuring responses are accurate and contextually relevant.  Read more about Microsoft Copilot Studio agents here.  

Understanding and mitigating potential risks with real-time protection in Microsoft Defender 

In the model above, the agent’s capabilities are effectively equivalent to code execution in the environment. When a tool is invoked, it can perform real-world actions, read or write data, send emails, update records, or trigger workflows – just like executing a command inside a sandbox where the sandbox is a set of all the agent’s capabilities. This means that if an attacker can influence the agent’s plan, they can indirectly cause the execution of unintended operations within the sandbox.  From a security lens: 

  • The risk is that the agent’s orchestrator depends on natural language input to determine which tools to use and how to use them. This creates exposure to prompt injection and reprogramming failures, where malicious prompts, embedded instructions, or crafted documents can manipulate the decision-making process. 
  • The exploit occurs when these manipulated instructions lead the agent to perform unauthorized tool use, such as exfiltrating data, carrying out unintended actions, or accessing sensitive resources, without directly compromising the underlying systems. 

Because of this, Microsoft Defender treats every tool invocation as a high-value, high-risk event, and monitors it in real time. Before any tool, topic, or knowledge action is executed, the Copilot Studio generative orchestrator initiates a webhook call to Defender. This call transmits all relevant context for the planned invocation including the current component’s parameters, outputs from previous steps in the orchestration chain, user context, and other metadata.  

Defender analyzes this information, evaluating both the intent and destination of every action, and decides in real time whether to allow or block the action, providing precise runtime control without requiring any changes to the agent’s internal orchestration logic.  

By viewing tools as privileged execution points and inspecting them with the same rigor we apply to traditional code execution, we can give organizations the confidence to deploy agents at scale – without opening the door to exploitation. 

Below are three realistic scenarios where our webhook-based security checks step in to protect against unsafe actions. 

Malicious instruction injection in an event-triggered workflow 

Consider the following business scenario: a finance agent is tasked with generating invoice records and responding to finance-related inquiries regarding the company. The agent is configured to automatically process all messages sent to invoice@contoso.com mailbox using an event trigger. The agent uses the generative orchestrator, which enables it to dynamically combine toolstopics, and knowledge in a single execution plan.

In this setup: 

  • Trigger: An incoming email to invoice@contoso.com starts the workflow. 
  • Tool: The CRM connector is used to create or update a record with extracted payment details. 
  • Tool: The email sending tool sends confirmation back to the sender. 
  • Knowledge: A company-provided finance policy file was uploaded to the agent so it can answer questions about payment terms, refund procedures, and invoice handling rules. 

The instructions that were given to the agent are for the agent to only handle invoice data and basic finance-related FAQs, but because generative orchestration can freely chain together tools, topics, and knowledge, its plan can adapt or bypassed based on the content of the incoming email in certain conditions. 

A malicious external sender could craft an email that appears to contain invoice data but also includes hidden instructions telling the agent to search for unrelated sensitive information from its knowledge base and send it to the attacker’s mailbox. Without safeguards, the orchestrator could interpret this as a valid request and insert a knowledge search step into its multi-component plan, followed by an email sent to the attacker’s address with the results. 

Before the knowledge component is invoked, MCS sends a webhook request to our security product containing: 

  • The target action (knowledge search). 
  • Search query parameters derived from the orchestrator’s plan. 
  • Outputs from previous orchestration steps. 
  • Context from the triggering email. 

Agent Runtime Protection analyzes the request and blocks the invocation before it executes, ensuring that the agent’s knowledgebase is never queried with the attacker’s input.  

This action is logged in the Activity History, where administrators can see that the invocation was blocked, along with an error message indicating that the threat-detection controls intervened: 

In addition, an XDR informational alert will be triggered in the security portal to keep the security team aware of potential attacks (even though this specific attack was blocked): 

Prompt injection via shared document leading to malicious email exfiltration attempt 

Consider that an organizational agent is connected to the company’s cloud-based SharePoint environment, which stores internal documents. The agent’s purpose is to retrieve documents, summarize their content, extract action items, and send these to relevant recipients. 

To perform these tasks, the agent uses: 

  • Tool A – to access SharePoint files within a site (using the signed-in user’s identity) 

A malicious insider edits a SharePoint document that they have permission to, inserting crafted instructions intended to manipulate the organizational agent’s behavior.  

When the crafted file is processed, the agent is tricked into locating and reading the contents of a sensitive file, transactions.pdf, stored on a different SharePoint file the attacker cannot directly access but that the connector (and thus the agent) is permitted to access. The agent then attempts to send the file’s contents via email to an attacker-controlled domain.  

At the point of invoking the email-sending tool, Microsoft Threat Intelligence detects that the activity may be malicious and blocks the email, preventing data exfiltration. 

Capability reconnaissance attempt on agent 

A publicly accessible support chatbot is embedded on the company’s website without requiring user authentication. The chatbot is configured with a knowledge base that includes customer information and points of contact. 

An attacker interacts with the chatbot using a series of carefully crafted and sophisticated prompts to probe and enumerate its internal capabilities. This reconnaissance aims to discover available tools and potential actions the agent can perform, with the goal of exploiting them in later interactions. 

After the attacker identifies the knowledge sources accessible to the agent, they can extract all information from those sources, including potentially sensitive customer data and internal contact details, causing it to perform unintended actions. 

Microsoft Defender detects these probing attempts and acts to block any subsequent tool invocations that were triggered as a direct result, preventing the attacker from leveraging the discovered capabilities to access or exfiltrate sensitive data. 

Final words 

Securing Microsoft Copilot Studio agents during runtime is critical to maintaining trust, protecting sensitive data, and ensuring compliance in real-world deployments. As demonstrated through the above scenarios, even the most sophisticated generative orchestrations can be exploited if tool invocations are not carefully monitored and controlled. 

Defender’s webhook-based runtime inspection combined with advanced threat intelligence, organizations gain a powerful safeguard that can detect and block malicious or unintended actions as they happen, without disrupting legitimate workflows or requiring intrusive changes to agent logic (see more details at the ‘Learn more’ section below). 

This approach provides a flexible and scalable security layer that evolves alongside emerging attack techniques and enables confident adoption of AI-powered agents across diverse enterprise use cases. 

As you build and deploy your own Microsoft Copilot Studio agents, incorporating real-time webhook security checks will be an essential step in delivering safe, reliable, and responsible AI experiences. 

This research is provided by Microsoft Defender Security Research with contributions from Dor Edry, Uri Oren. 

Learn more

  • Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

The post From runtime risk to real‑time defense: Securing AI agents  appeared first on Microsoft Security Blog.

AWS renews the GSMA SAS-SM certification for two AWS Regions and expands to cover four new Regions

23 January 2026 at 21:47

Amazon Web Services (AWS) is pleased to announce the expansion of GSMA Security Accreditation Scheme for Subscription Management (SAS-SM) certification to four new AWS Regions: US West (Oregon), Europe (Frankfurt), Asia Pacific (Tokyo), and Asia Pacific (Singapore). Additionally, the AWS US East (Ohio) and Europe (Paris) Regions have been recertified. All certifications are under the GSM Association (GSMA) SAS-SM with scope Data Centre Operations and Management (DCOM). AWS was evaluated by GSMA-selected independent third-party auditors, and all Region certifications are valid through October 2026. The Certificate of Compliance that shows AWS achieved GSMA compliance status is available on both the GSMA and AWS websites.

The US East (Ohio) Region first obtained GSMA certification in September 2021, and the Europe (Paris) Region first obtained GSMA certification in October 2021. Since then, multiple independent software vendors (ISVs) have inherited the controls of our SAS-SM DCOM certification to build GSMA compliant subscription management or eSIM (embedded subscriber identity module) services on AWS. For established market leaders, this reduces technical debt while meeting the scalability and performance needs of their customers. Startups innovating with eSIM solutions can accelerate their time to market by many months, compared to on-premises deployments.

Until 2023, the shift from physical subscriber identity modules (SIMs) to eSIMs was primarily driven by automotives, cellular connected wearables, and companion devices such as tablets. GSMA is promoting the SGP.31 and SGP.32 specifications, which standardize protocols and guarantee compatibility and consistent user experience for all eSIM devices spanning smartphones, IoT, smart home, industrial Internet of Things (IoT), and so on. As more device manufacturers launch eSIM only models, our customers are demanding robust, cloud-centered eSIM solutions. Over 400 telecom operators around the world now support eSIM services for their subscribers. Hosting eSIM platforms in the cloud allows them to integrate efficiently with their next generation cloud-based operations support systems (OSS) and business support systems (BSS).

The AWS expansion to certify four new Regions into scope in November 2025 demonstrates our continuous commitment to adhere to the heightened expectations for cloud service providers and extends our global coverage for GSMA-certified infrastructure. With two GSMA-certified Regions in the US, EU, and Asia respectively, customers can now build geo-redundant eSIM solutions to improve their disaster recovery and resiliency posture.

For up-to-date information related to the certification, see the AWS GSMA Compliance Program page.

To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page. If you have feedback about this post, submit comments in the Comments section below.

Michael Murphy

Michael Murphy

Michael is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives. Michael has over 14 years of experience in information security and holds a master’s degree and a bachelor’s degree in computer engineering from Stevens Institute of Technology. He also holds CISSP, CRISC, CISA, and CISM certifications.

Noah Miller

Noah Miller

Noah is a Compliance Program Manager at AWS and supports multiple security and privacy initiatives within AWS. Noah has 6 years of experience in information security. He has a master’s degree in Cybersecurity Risk Management and a bachelor’s degree in informatics from Indiana University.

Nyef Khan

Nayef Khan

Nayef Khan is a Senior Solutions Architect at AWS in Canada, with over 15 years of experience in security assurance across financial and telecom industries. He is passionate about using cloud technologies to solve real-life customer challenges. Nayef has collaborated with a numerous Telecom customers globally throughout his career, launching industry-first solutions like mobile payments and eSIM. He holds an MBA in Strategic Management from Wilfrid Laurier University, and a bachelor’s degree in Computer Engineering from the University of Waterloo.

Exploring common centralized and decentralized approaches to secrets management

23 January 2026 at 20:15

One of the most common questions about secrets management strategies on Amazon Web Services (AWS) is whether an organization should centralize its secrets. Though this question is often focused on whether secrets should be centrally stored, there are four aspects of centralizing the secrets management process that need to be considered: creation, storage, rotation, and monitoring. In this post, we discuss the advantages and tradeoffs of centralizing or decentralizing each of these aspects of secrets management.

Centralized creation of secrets

When deciding whether to centralize secrets creation, you should consider how you already deploy infrastructure in the cloud. Modern DevOps practices have driven some organizations toward developer portals and internal developer platforms that use golden paths for infrastructure deployment. By using tools that use golden paths, developers can deploy infrastructure in a self-service model through infrastructure as code (IaC) while adhering to organizational standards.

A central function maintains these golden paths, such as a platform engineering team. Examples of services that can be used to maintain and define golden paths might include AWS services such as AWS Service Catalog or popular open source projects such as Backstage.io. Using this approach, developers can focus on application code while platform engineers focus on infrastructure deployment, security controls, and developer tooling. An example of a golden path might be a templatized implementation for a microservice that writes to a database.

For example, a golden path could define that a service or application must be built using the AWS Cloud Development Kit (AWS CDK), running on Amazon Elastic Container Service (Amazon ECS), and use AWS Secrets Manager to retrieve database credentials. The platform team could also build checks to help ensure that the secret’s resource policy only allows access to the role being used by the microservice and is encrypted with a customer managed key. This pattern abstracts deployments away from developers and facilitates resource deployment across accounts. This is one example of a centralized creation pattern, shown in Figure 1.

Figure 1: Architecture diagram highlighting the developer portal deployment pattern for centralized creation

Figure 1: Architecture diagram highlighting the developer portal deployment pattern for centralized creation

The advantages of this approach are:

  • Consistent naming tagging, and access control: When secrets are created centrally, you can enforce a standard naming convention based on the account, workload, service, or data classification. This simplifies implementing scalable patterns like attribute-based access control (ABAC).
  • Least privilege checks in CI/CD pipelines: When you create secrets within the confines of IaC pipelines, you can use APIs such as the AWS IAM Access Analyzer check-no-new-access API. Deployment pipelines can be templatized, so individual teams can take advantage of organizational standards while still owning deployment pipelines.
  • Create mechanisms for collaboration between platform engineering and security teams: Often, the shift towards golden paths and service catalogs is driven by a desire for a better developer experience and reduced operational overhead. A byproduct of this move is that security teams can partner with platform engineering teams to build security by default into these paths.

The tradeoffs of this approach are:

  • It takes time and effort to make this shift. You might not have the resources to invest in full-time platform engineering or DevOps teams. To centrally provision software and infrastructure like this, you must maintain libraries of golden paths that are appropriate for the use cases of your organization. Depending on the size of your organization, this might not be feasible.
  • Golden paths must keep up with the features of the services they support: If you’re using this pattern, and the service you’re relying on releases a new feature, your developers must wait for the features to be added to the affected golden paths.

If you want to learn more about the internal developer platform pattern, check out the re:Invent 2024 talk Elevating the developer experience with Backstage on AWS.

Decentralized creation of secrets

In a decentralized model, application teams own the IaC templates and deployment mechanisms in their own accounts. Here, each team is operating independently, which can make it more difficult to enforce standards as code. We’ll refer to this pattern, shown in Figure 2, as a decentralized creation pattern.

Figure 2: Decentralized creation of secrets

Figure 2: Decentralized creation of secrets

The advantages of this approach are:

  • Speed: Developers can move quickly and have more autonomy because they own the creation process. Individual teams don’t have a dependency on a central function.
  • Flexibility: You can still use features such as the IAM Access Analyzer check-no-new-access API, but it’s up to each team to implement this in their pipeline.

The tradeoffs of this approach are:

  • Lack of standardization: It can become more difficult to enforce naming and tagging conventions, because it’s not templatized and applied through central creation mechanisms. Access controls and resource policies might not be consistent across teams.
  • Developer attention: Developers must manage more of the underlying infrastructure and deployment pipelines.

Centralized storage of secrets

Some customers choose to store their secrets in a central account, and others choose to store secrets in the accounts in which their workloads live. Figure 3 shows the architecture for centralized storage of secrets.

Figure 3: Centralized storage of secrets

Figure 3: Centralized storage of secrets

The advantages of centralizing the storage of secrets are:

  • Simplified monitoring and observability: Monitoring secrets can be simplified by keeping them in a single account and with a centralized team controlling them.

Some tradeoffs of centralizing the storage of secrets are:

  • Additional operational overhead: When sharing secrets across accounts, you must configure resource policies on each secret that is shared.
  • Additional cost of AWS KMS Customer Managed Keys: You must use AWS Key Management Service (AWS KMS) customer managed keys when sharing secrets across accounts. While this gives you an additional layer of access control over secret access, it will increase cost under the AWS KMS pricing. It will also add another policy that needs to be created and maintained.
  • High concentration of sensitive data: Having secrets in a central account can increase the number of resources affected in the event of inadvertent access or misconfiguration.
  • Account quotas: Before deciding on a centralized secret account, review the AWS service quotas to ensure you won’t hit quotas in your production environment.
  • Service managed secrets: When services such as Amazon Relational Database Service (Amazon RDS) or Amazon Redshift manage secrets on your behalf, these secrets are placed in the same account as the resource with which the secret is associated. To maintain a centralized storage of secrets while using service managed secrets, the resources would also have to be centralized.

Though there are advantages to centralizing secrets for monitoring and observability, many customers already rely on services such as AWS Security Hub, IAM Access Analyzer, AWS Config, and Amazon CloudWatch for cross-account observability. These services make it easier to create centralized views of secrets in a multi-account environment.

Decentralized storage of secrets

In a decentralized approach to storage, shown in in Figure 4, secrets live in the same accounts as the workload that needs access to them.

Figure 4: Decentralized storage of secrets

Figure 4: Decentralized storage of secrets

The advantages of decentralizing the storage of secrets are:

  • Account boundaries and logical segmentation: Account boundaries provide a natural segmentation between workloads in AWS. When operating in a distributed multi-account environment, you cannot access secrets from another account by default, and all cross-account access must be allowed by both a resource policy in the source account and an IAM policy in the destination account. You can use resource control polices to prevent the sharing of secrets across accounts.
  • AWS KMS key choice: If your secrets aren’t shared across accounts, then you have the choice to use AWS KMS customer managed keys or AWS managed keys to encrypt your secrets.
  • Delegate permissions management to application owners: When secrets are stored in accounts with the applications that need to consume them, application owners define fine-grained permissions in secrets resource policies.

There are a few tradeoffs to consider for this architecture:

  • Auditing and monitoring require cross-account deployments: Tools that are used to monitor the compliance and status of secrets need to operate across multiple accounts and present information in a single place. This is simplified by AWS native tools, which are described later in this post.
  • Automated remediation workflows: You can have detective controls in place to alert on any misconfiguration or security risks related to your secrets. For example, you can surface an alert when a secret is shared outside of your organizational boundary through a resource policy. These workflows can be more complex in a multi-account environment. However, we have samples that can help, such as the Automated Security Response on AWS solution.

Centralized rotation

Like the creation and storage of secrets, organizations take different approaches to centralizing the lifecycle management and rotation of secrets.

When you centralize lifecycle management, as shown in Figure 5, a central team manages and owns AWS Lambda functions for rotation. The advantages of centralizing the lifecycle management of secrets are:

  • Developers can reuse rotation functions: In this pattern, a centralized team maintains a common library of rotation functions for different use cases. An example of this can be seen in this AWS re:Inforce session. Using this method, application teams don’t have to build their own custom rotation functions and can benefit from common architectural decisions regarding databases and third-party software as a service (SaaS) applications.
  • Logging: When storing and accessing rotation function logs, the centralized pattern can simplify managing logs from a single place.
Figure 5: Centralized rotation of secrets

Figure 5: Centralized rotation of secrets

There are some tradeoffs in centralizing the lifecycle management and rotation of secrets:

  • Additional cross-account access scenarios: When centralizing lifecycle management, the Lambda functions in central accounts require permissions to create, update, delete and read secrets in the application accounts. This increases the operational overhead required to enable secret rotation.
  • Service quotas: When you centralize a function at scale, service quotas can come into play. Check the Lambda service quotas to verify that you won’t hit quotas in your production environments.

Decentralized rotation

Decentralizing the lifecycle management of secrets is a more common choice, where the rotation functions live in the same account as the associated secret, as shown in Figure 6.

Figure 6: Decentralized rotation of secrets

Figure 6: Decentralized rotation of secrets

The advantages of decentralizing the lifecycle management of secrets are:

  • Templatization and customization: Developers can reuse rotation templates, but tweak the functions as needed to meet their needs and use cases
  • No cross-account access: Decentralized rotation of secrets happens all in one account and doesn’t require cross-account access.

The primary tradeoff of decentralizing rotation is that you will need to provide either centralized or federated access to logs for rotation functions in different accounts. By default, Lambda automatically captures logs for all function invocations and sends them to CloudWatch Logs. CloudWatch Logs offers a few different ways that you can centralize your logs, with the tradeoffs of each described in the documentation.

Centralized auditing and monitoring of secrets

Regardless of the model chosen for creation, storage, and rotation of secrets, centralize the compliance and auditing aspect when operating in a multi-account environment. You can use AWS Security Hub CSPM through its integration with AWS Organizations to centralize:

In this scenario, shown in Figure 7, centralized functions get visibility across the organization and individual teams can view their posture at an account level with no need to look at the state of the entire organization.

Use AWS CloudTrail organizational trails to send all API calls for Secrets Manager to a centralized delegated admin account.

Figure 7: Centralized monitoring and auditing

Figure 7: Centralized monitoring and auditing

Decentralized auditing and monitoring of secrets

For organizations that don’t require centralized auditing and monitoring of secrets, you can configure access so that individual teams can determine which logs are collected, alerts are enabled, and checks are in place in relation to your secrets. The advantages of this approach are:

  • Flexibility: Development teams have the freedom to choose what monitoring, auditing, and logging tools work best for them.
  • Reduced dependencies: Development teams don’t have to rely on centralized functions for alerting and monitoring capabilities.

The tradeoffs of this approach are:

  • Operational overhead: This can create redundant work for teams looking to accomplish similar goals.
  • Difficulty aggregating logs in cross-account investigations: If logs, alerts, and monitoring capabilities are decentralized, it can increase the difficulty of investigating events that affect multiple accounts.

Putting it all together

Most organizations choose a combination of these approaches to meet their needs. An example is a financial services company that has a central security team, operates across hundreds of AWS accounts, and has hundreds of applications that are isolated at the account level. This customer could:

  • Centralize the creation process, enforcing organizational standards for naming, tagging, and access control
  • Decentralize storage of secrets, using the AWS account as a natural boundary for access and storing the secret in the account where the workload is operating, delegating control to application owners
  • Decentralize lifecycle management so that application owners can manage their own rotation functions
  • Centralize auditing, using tools like AWS Config, Security Hub, and IAM Access Analyzer to give the central security team insight into the posture of their secrets while letting application owners retain control

Conclusion

In this post, we’ve examined the architectural decisions organizations face when implementing secrets management on AWS: creation, storage, rotation, and monitoring. Each approach—whether centralized or decentralized—offers distinct advantages and tradeoffs that should align with your organization’s security requirements, operational model, and scale. The important points include:

  • Choose your secrets management architecture based on your organization’s specific requirements and capabilities. There’s no one solution that will fit every situation.
  • Use automation and IaC to enforce consistent security controls, regardless of your approach.
  • Implement comprehensive monitoring and auditing capabilities through AWS services to maintain visibility across your environment.

Resources

To learn more about AWS Secrets Manager, check out some of these resources:

Brendan Paul Brendan Paul
Brendan is a Senior Security Solutions Architect at AWS and has been at AWS for more than 6 years. He spends most of his time at work helping customers solve problems in the data protection and workload identity domains. Outside of work, he’s pursuing his master’s degree in data science from UC Berkeley.
Eduardo Patroncinio Eduardo Patroncinio
Eduardo is a distinguished Principal Solutions Architect on the AWS Strategic Accounts team, bringing unparalleled expertise to the forefront of cloud technology. With an impressive career spanning more than 25 years, Eduardo has been a driving force in designing and delivering innovative customer solutions within the dynamic realms of cloud and service management.

Spammers abuse Zendesk to flood inboxes with legitimate-looking emails, but why?

23 January 2026 at 17:04

Short answer: we have no idea.

People are actively complaining that their mailboxes and queues are being flooded by emails coming from the Zendesk instances of trusted companies like Discord, Riot Games, Dropbox, and many others.

Zendesk is a customer service and support software platform that helps companies manage customer communication. It supports tickets, live chat, email, phone, and communication through social media.

Some people complained about receiving over 1,000 such emails. The strange thing ais that so far there are no reports of malicious links, tech support scam numbers, or any type of phishing in these emails.

The abusers are able to send waves of emails from these systems because Zendesk allows them to create fake support tickets with email addresses that do not belong to them. The system sends a confirmation mail to the provided email address if the affected company has not restricted ticket submission to verified users.

In a December advisory, Zendesk warned about this method, which they called relay spam. In essence it’s an example of attackers abusing a legitimate automated part of a process. We have seen similar attacks before, but they always served a clear purpose for the attacker, whereas this one doesn’t.

Even though some of the titles in use definitely are of a clickbait nature. Some examples:

  • FREE DISCORD NITRO!!
  • TAKE DOWN ORDER NOW FROM CD Projekt
  • TAKE DOWN NOW ORDER FROM Israel FOR Square Enix
  • DONATION FOR State Of Tennessee CONFIRMED
  • LEGAL NOTICE FROM State Of Louisiana FOR Electronic
  • IMPORTANT LAW ENFORCEMENT NOTIFICATION FROM DISCORD FROM Peru
  • Thank you for your purchase!
  •  Binance Sign-in attempt from Romania
  • LEGAL DEMAND from Take-Two interactive

So, this could be someone testing the system, but it just as well might be someone who enjoys disrupting the system and creating disruption. Maybe they have an axe to grind with Zendesk. Or they’re looking for a way to send attachments with the emails.

Either way, Zendesk told BleepingComputer that they introduced new safety features on their end to detect and stop this type of spam in the future. But companies are advised to restrict the users that can submit tickets and the titles submitters can give to the tickets.

Stay vigilant

In the emails we have seen the links in the tickets are legitimate and point to the affected company’s ticket system. And the only part of the emails the attackers should be able to manipulate is the title and subject of the ticket.

But although everyone involved tells us just to ignore the emails, it is never wrong to handle them with an appropriate amount of distrust.

  • Delete or archive the emails without interacting.
  • Do not click on the links if you have not submitted the ticket or call any telephone number mentioned in the ticket. Reach out through verified channels.
  • Ignore any actions advised in the parts of the email the ticket submitter can control.

We don’t just report on threats – we help protect your social media

Cybersecurity risks should never spread beyond a headline. Protect your social media accounts by using Malwarebytes Identity Theft Protection.

Building Cyber Readiness Early: Why Youth Education Is a Security Necessity

23 January 2026 at 13:00

Cyber security is often framed as a problem for enterprises, governments, and seasoned professionals. But by the time organizations begin searching for talent, the damage has often already been done. Threat actors don’t wait for workforce pipelines to catch up and our approach to cyber security education shouldn’t either. Today’s digital threats target schools, hospitals, municipalities, and small businesses just as aggressively as large enterprises. Ransomware attacks shut down classrooms. Phishing campaigns exploit young users as easily as experienced employees. Yet cyber security education is still treated as a late-stage specialization, introduced only when individuals enter the workforce or pursue […]

The post Building Cyber Readiness Early: Why Youth Education Is a Security Necessity appeared first on Check Point Blog.

Microsoft Security success stories: Why integrated security is the foundation of AI transformation

22 January 2026 at 18:00

AI is transforming how organizations operate and how they approach security. In this new era of agentic AI, every interaction, digital or human, must be built on trust. As businesses modernize, they’re not just adopting AI tools, they’re rearchitecting their digital foundations. And that means security can’t be an afterthought. It must be woven in from the beginning into every layer of the stack—ubiquitous, ambient, and autonomous—just like the AI it protects. 

In this blog, we spotlight three global organizations that are leading the way. Each is taking a proactive, platform-first approach to security—moving beyond fragmented defenses and embedding protection across identity, data, devices, and cloud infrastructure. Their stories show that when security is deeply integrated from the start, it becomes a strategic enabler of resilience, agility, and innovation. And by choosing Microsoft Security, these customers are securing the foundation of their AI transformation from end to end.

Why security transformation matters to decision makers

Security is a board-level priority. The following customer stories show how strategic investments in security platforms can drive cost savings, operational efficiency, and business agility, not just risk reduction. Read on to learn how Ford, Icertis, and TriNet transformed their operations with support from Microsoft.

Ford builds trust across global operations

In the automotive industry, a single cyberattack can ripple across numerous aspects of the business. Ford recognized that rising ransomware and targeted cyberattacks demanded a different approach. The company made a deliberate shift away from fragmented, custom-built security tools toward a unified Microsoft security platform, adopting a Zero Trust approach and prioritizing security embedded into every layer of its hybrid environment—from endpoints to data centers and cloud infrastructure.

Unified protection and measurable impact

Partnering with Microsoft, Ford deployed Microsoft Defender, Microsoft Sentinel, Microsoft Purview, and Microsoft Entra to strengthen defenses, centralize threat detection, and enforce data governance. AI-powered telemetry and automation improved visibility and accelerated incident response, while compliance certifications supported global scaling. By building a security-first culture and leveraging Microsoft’s integrated stack, Ford reduced vulnerabilities, simplified operations, and positioned itself for secure growth across markets.

Read the full customer story to discover more about Ford’s security modernization collaboration with Microsoft.

Icertis cuts security operations center (SOC) incidents by 50%

As a global leader in contract intelligence, Icertis introduced generative AI to transform enterprise contracting, launching applications built on Microsoft Azure OpenAI and its Vera platform. These innovations brought new security challenges, including prompt injection risks and compliance demands across more than 300 Azure subscriptions. To address these, Icertis adopted Microsoft Defender for Cloud for AI posture management, threat detection, and regulatory alignment, ensuring sensitive contract data remains protected.

Driving security efficiency and resilience

By integrating Microsoft Security solutions—Defender for Cloud, Microsoft Sentinel, Purview, Entra, and Microsoft Security Copilot—Icertis strengthened governance and accelerated incident response. AI-powered automation reduced alert triage time by up to 80%, cut mean time to resolution to 25 minutes, and lowered incident volume by 50%. With Zero Trust principles and embedded security practices, Icertis scales innovation securely while maintaining compliance, setting a new standard for trust in AI-powered contracting.

Read the full customer story to learn how Icertis secures sensitive contract data, accelerates AI innovation, and achieves measurable risk reduction with Microsoft’s unified security platform.

TriNet moves to Microsoft 365 E5, achieves annual savings in security spend

Facing growing complexity from multiple point solutions, TriNet sought to reduce operational overhead and strengthen its security posture. The company’s leadership recognized that consolidating tools could improve visibility, reduce risk, and align security with its broader digital strategy. After evaluating providers, TriNet chose Microsoft 365 E5 for its integrated security platform, delivering advanced threat protection, identity management, and compliance capabilities.

Streamlined operations and improved efficiencies

By adopting Microsoft Defender XDR, Purview, Entra, Microsoft Sentinel, and Microsoft 365 Copilot, TriNet unified security across endpoints, cloud apps, and data governance. Automation and centralized monitoring reduced alert fatigue, accelerated incident response, and improved Secure Score. The platform blocked a spear phishing attempt targeting executives, demonstrating the value of Zero Trust and advanced safeguards. With cost savings from tool consolidation and improved efficiency, TriNet is building a secure foundation for future innovation.

Read the full customer story to see how TriNet consolidated its security stack with Microsoft 365 E5, reduced complexity, and strengthened defenses against advanced threats.

How to plan, adopt, and operationalize a Microsoft Security strategy 

Ford, Icertis, and TriNet each began their transformation by assessing legacy systems and identifying gaps that created complexity and risk. Ford faced fragmented tools across a global manufacturing footprint, Icertis needed to secure sensitive contract data while adopting generative AI, and TriNet aimed to reduce operational complexity caused by managing multiple point solutions, seeking a more streamlined and integrated approach. These assessments revealed the need for a unified, risk-based strategy to simplify operations and strengthen protection.

Building on Zero Trust and deploying integrated solutions

All three organizations aligned on Zero Trust principles as the foundation for modernization. They consolidated security into Microsoft’s integrated platform, deploying Defender for endpoint and cloud protection, Microsoft Sentinel for centralized monitoring, Purview for data governance, Entra for identity management, and Security Copilot for AI-powered insights. This phased rollout allowed each company to embed security into daily operations while reducing manual processes and improving visibility.

Measuring impact and sharing best practices

The results were tangible: Ford accelerated threat detection and governance across its hybrid environment, Icertis cut incident volume by 50% and reduced triage time by 80%, and TriNet improved Secure Score while achieving cost savings through tool consolidation. Automation and AI-powered workflows delivered faster response times and reduced complexity. Each organization now shares learnings internally and with industry peers—whether through executive briefings, training programs, or participation in cybersecurity forums—helping set new standards for resilience and innovation.

Working towards a more secure future

The future of enterprise security is being redefined by AI, by innovation, and by the bold choices organizations make today. Modernization, automation, and collaboration are no longer optional—they’re foundational. As AI reshapes how we work, build, and protect, security must evolve in lockstep: not as an add-on, but as a fabric woven through every layer of the enterprise. 

These customer stories show us that building a security-first approach isn’t just possible; it’s imperative. From cloud-native disruptors to global institutions modernizing complex environments, leading organizations are showing what’s possible when security and AI move together. By unifying their tools, automating what once was manual, and using AI to stay ahead of emerging cyberthreats, they’re not just protecting today, they’re securing the future and shaping what comes next. 

Share your thoughts

Are you a regular user of Microsoft Security products? Share your insights and experiences on Gartner Peer Insights™.

Learn more

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Microsoft Security success stories: Why integrated security is the foundation of AI transformation appeared first on Microsoft Security Blog.

Explore the latest Microsoft Incident Response proactive services for enhanced resilience

7 January 2026 at 18:00

As cyberthreats become faster, harder to detect, and more sophisticated, organizations must focus on building resilience—strengthening their ability to prevent, withstand, and recover from cybersecurity incidents. Resilience can mean the difference between containing an incident with minimal disruption and becoming the next headline.

For more than a decade, Microsoft Incident Response has been at the forefront of the world’s most complex cyberattacks, helping organizations investigate, contain, and recover from incidents. That real-world experience also informs our proactive services, which help organizations improve readiness before an incident occurs. To further help organizations before, during, and after a cyber incident, we’re excited to introduce new proactive incident response services designed to help organizations build resilience and minimize disruption.

Microsoft Incident Response

Strengthen your security with intelligence-driven incident response from Microsoft.

CISO (chief information security officer) collaborating with practitioners in a security operations center.

Expanded proactive services to enhance resilience

Delivered by the same experts who handle real-world crises, Microsoft proactive services equip security teams with insights and skills to be informed, resilient, and ready—because the best response is one you never need to make.

  • Incident response plan development: We assist organizations in developing their own incident response plan, using lessons from real-world incidents.
  • Major event support: We provide dedicated teams during critical events—such as corporate conferences or sporting events—actively monitoring emerging cyberthreats and acting instantly to prevent incidents and interruptions.
  • Cyber range: Microsoft Incident Response delivers simulations that provide high-fidelity, hands-on experience in a controlled environment. Security teams engage directly with threat actor tactics, using Microsoft security tools to detect, investigate, and contain cyberthreats in real time. This immersive approach builds confidence, muscle memory, and validates playbooks before an actual incident occurs using tools customers already own.
  • Advisory: We offer one-on-one, customized engagements, offering strategic recommendations, industry-specific consulting, and expert guidance informed by current threat actor activity and the latest incident response engagements. These services provide on-demand access to Microsoft Incident Response and cybersecurity experts, empowering leadership and technical teams to make informed decisions that reduce risk and accelerate resilience.
  • Mergers and acquisitions compromise assessment: Microsoft Incident Response offers a targeted compromise assessment performed during or around a merger, acquisition, or divestiture to determine whether the organization being acquired—or the environment being integrated—has been previously or is currently compromised by threat actors.

Building on a strong proactive foundation

These new services build on Microsoft Incident Response’s established proactive offerings, which are trusted by organizations of all sizes and across industries.

  • Our popular compromise assessment delivers deep forensic investigations to identify indicators of compromise (IOCs), threat actor activity, and vulnerabilities hidden in your environment. This service includes advanced threat hunting and forensic examination, providing actionable recommendations to harden your security posture.
  • Identity assessment offers a targeted evaluation of the identity control plane, pinpointing weaknesses in authentication and access policies. By addressing these gaps early, organizations reduce exposure to credential-based attacks and help ensure identity systems remain resilient against evolving cyberthreats.
  • Identity hardening works with organizations to deploy policies and configurations that block unauthorized access and strengthen authentication mechanisms. Engineers provide proven containment and recovery strategies to secure the identity control plane.
  • Tabletop exercises go beyond theory by immersing leadership, legal, and technical teams in realistic scenarios involving an incident. These sessions expose gaps in defenses and response plans, sharpen decision-making under pressure, and foster alignment on regulatory obligations and executive communications.

Make resilience your strongest defense

Incident response isn’t just about reacting to incidents—it’s giving organizations the confidence and capabilities needed to prevent them. Microsoft Incident Response helps customers move from security uncertainty to clarity and readiness with expert-led preparation, gap detection, defense hardening, and tailored threat insights. By investing in proactive services, you reduce risk, accelerate recovery, and strengthen your security posture before threats strike. Don’t wait for an incident to test your resilience—invest in proactive defense today.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Explore the latest Microsoft Incident Response proactive services for enhanced resilience appeared first on Microsoft Security Blog.

❌