Security in the agentic era: A new paradigm
Trust is the new control plane: A security leader's guide to the age of AI agents Artificial intelligence is no longer a background utility — it's becoming an autonomous workforce. As AI agents take on independent roles in business processes, organizations must confront a new class of security, governance, and compliance challenges that traditional frameworks were never designed to handle. The question is no longer whether to adopt AI. It's whether your organization can do so without creating unacceptable risk. This guide examines the three pillars every security and technology leader must address: securing AI systems, governing AI behavior, and complying with a rapidly evolving regulatory landscape. Why the Stakes Are Higher Than Ever By 2027, Microsoft projects that more than 1.3 billion AI agents will be deployed globally — a number that rivals the entire US population. These aren't passive tools waiting for instructions. They are autonomous systems operating around the clock, accessing privileged data, executing decisions, and interacting with customers, suppliers, and internal workflows — all without a human explicitly in the loop for every action. For security leaders, the implications are immediate and stark: 1.3 billion non-human identities to manage and secure 1.3 billion autonomous workflows capable of triggering real-world consequences 1.3 billion new attack surfaces that existing security architectures weren't built to defend The Microsoft Work Trend Index reinforces the urgency: 95% of organizations are already using AI in some form. Yet only a single-digit percentage of leaders feel confident enough to deploy generative or agentic AI at enterprise scale. The gap between adoption and readiness is significant — and it's widening. Closing that gap starts with one thing: trust. Nobody builds a digital workforce on a foundation they can't rely on. The Shifting Threat Landscape The World Economic Forum's top global risks through 2035 paint a sobering picture of where we're headed. Misinformation and disinformation rank among the top five risks — and AI is accelerating both. AI-generated phishing attacks now achieve click rates up to four times higher than traditional attempts. There are no spelling mistakes. The logos are perfect. The tone matches your organization's communication style. Employees who were trained to spot obvious red flags are encountering attacks that look entirely legitimate. But phishing is only part of the threat surface. The broader risks include: Data oversharing — AI agents inadvertently exposing sensitive information across organizational and jurisdictional boundaries Adverse AI outcomes — biased, inaccurate, or non-compliant outputs that create legal liability and reputational damage Cyber espionage — the same autonomous capabilities that make AI agents powerful make them attractive targets for nation-state actors and sophisticated adversaries The fundamental principles of good security hygiene haven't changed. But the autonomy and scale at which AI systems now operate means any failure can propagate faster and further than anything we've dealt with before. Pillar one — securing AI: Getting the foundation right Rethinking data loss prevention for the agentic era Controlling what data AI agents can access and share is one of the most immediate operational challenges organizations face. Traditional Data Loss Prevention (DLP) systems were built around known identifiers — matching patterns in email traffic, file transfers, and endpoint activity. Agentic systems operating through APIs and Model Context Protocol (MCP) servers don't fit those models. To address this, organizations must retrofit existing DLP controls for API-based and agent-driven data flows, while also building new capabilities: Discover and classify data before AI indexes it — legacy data that was never formally classified becomes a serious liability the moment an AI system can read and surface it at machine speed Implement agent-aware role-based access controls (RBAC) — access policies designed for human users often fail to account for the broader reach of autonomous agents Manage data lifecycle actively — data retained beyond its useful or legal life becomes an unnecessary risk vector; organizations need clear policies on retention, restriction, and secure deletion Prompt injection and the new attack surface Agentic AI has introduced a genuinely new class of attack. An adversary no longer needs to deploy malware in the conventional sense. Instead, they can embed hidden instructions in a document, an email, or an API response — and if an AI agent reads it, it may execute those instructions as legitimate commands. Prompt injection attacks represent a fundamental shift in the threat model. Every input channel to an agent — a document upload, an API call, a user prompt, an external data feed — is a potential attack vector. Sanitizing and validating inputs before they reach the model is no longer optional security hygiene; it's a core architectural requirement. Other significant threats emerging in this space include: Model theft — adversaries targeting the fine-tuned intellectual property embedded in proprietary AI models Hallucination exploitation — fabricated or omitted information leading to biased, incorrect, or legally non-compliant outputs Autonomous decision overreliance — trusting agent outputs without adequate human review, creating exposure to data leakage and incorrect actions executed at scale Tackling shadow AI A decade ago, "shadow IT" — employees using unapproved technology outside of IT oversight — was a governance nightmare. Shadow AI is the next chapter of that problem, and it's already here. Employees are adopting AI tools independently, often without any visibility from security or compliance teams. Without centralized oversight, there's no way to verify that those tools follow responsible AI principles, handle data appropriately, or comply with applicable regulations. A centralized AI tool policy — clearly defining which systems are approved and why — is essential. The goal isn't to limit innovation. It's to ensure that when AI is used, it can be trusted, explained, and audited. Pillar two — governing AI: Accountability at scale Security controls protect the system from external threats. Governance determines how the system behaves — and who is accountable when things go wrong. Data governance as the foundation AI systems are only as trustworthy as the data they are trained on and operate against. Poor data governance doesn't just create compliance risk — it undermines the reliability of every AI output. Effective data governance in the agentic era requires: Clear data ownership and access policies that explicitly cover non-human identities Centralized data catalogs with lineage tracking, quality controls, and metadata management AI agent identity lifecycle management — onboarding, access reviews, and offboarding for agents, managed with the same rigor applied to human employees Some leading organizations are already registering AI agents in HR systems and assigning human managers to each one. It's an imperfect analogy, but it enforces one critical discipline: making someone responsible for what the agent does. A framework for AI governance Effective AI governance rests on two foundations: core principles and an implementation framework that spans the full AI lifecycle. Core principles should address transparency in decision-making, clear accountability for outcomes, privacy protections for sensitive data, and meaningful human oversight for high-stakes decisions. These aren't abstract values — they need to be operationalized into specific technical controls and policy requirements. Governance itself typically runs through three phases: Selection — evaluating AI tools and models for safety, transparency, and compliance fit before adoption Deployment — aligning policies and controls to measurable business objectives so success can actually be verified Ongoing monitoring — continuously assessing performance, fairness, and regulatory compliance over the system's lifetime One area that remains persistently underinvested: monitoring outputs, not just inputs. Most organizations build controls around what goes into an AI system. But AI operates at machine scale and speed — organizations equally need the capability to watch what's coming out, in real time. The agent-as-employee mental model One of the most practical governance frameworks emerging in this space is treating every AI agent like a new employee. Define its job description: what is it authorized to do? What data can it access? Under what conditions does it need a human manager's approval before acting? If an agent needs access to a new database, who approves that request? If it begins exhibiting anomalous behavior, who receives the alert? If it needs to be decommissioned, what does offboarding look like? These questions aren't just governance formalities. They are the building blocks of accountability in the agentic era — and the organizations that answer them clearly will be far better positioned than those that don't. Pillar three — compliance: Shift left or fall behind With 127 countries now enforcing privacy laws, and AI-specific regulations evolving roughly every four to five days, compliance has become a fast-moving target. The EU AI Act, GDPR, DORA, the Cyber Resilience Act — these frameworks overlap, interact, and frequently conflict in ways that create genuine decision fatigue for compliance teams. The answer is not to wait for the landscape to stabilize. It won't. The only viable strategy is to shift compliance left — embedding regulatory requirements into architecture and process design from day one, rather than trying to retrofit them after deployment. In practice, this means: Aligning to established baselines such as ISO 42001 (AI Management Systems) rather than custom frameworks that can't be readily demonstrated to external regulators or auditors Mapping extraterritorial regulatory scope — understanding which laws apply to your data flows based on where data originates, where it's processed, and where it's used, not just where your headquarters sits Operationalizing responsible AI principles — translating commitments to privacy, explainability, and fairness into concrete technical controls, documented policies, and auditable practices The principle of shared responsibility — well understood in cloud computing — applies equally to AI deployment. A platform provider can build AI systems assessed against responsible AI principles, with transparency records publicly available. But the organization deploying those systems still owns its governance choices, its data handling practices, and its accountability to regulators and customers. Microsoft Marketplace: Where trust becomes a procurement decision All of the security, governance, and compliance principles discussed above ultimately converge at a practical decision point: where and how you acquire AI agents matters as much as how you deploy them. This is where Microsoft Marketplace enters the picture — and it's more significant than simply a software storefront. In September 2025, Microsoft unified Azure Marketplace and AppSource into a single Microsoft Marketplace, with a dedicated "AI Apps and Agents" category featuring over 3,000 solutions. The strategic intent is clear: make trusted AI agents as easy to discover, evaluate, and procure as any enterprise software — with governance and security built into the acquisition process itself. Two agent types, different security profiles For software development companies publishing agents and enterprises evaluating them, Microsoft Marketplace distinguishes between two categories, each with distinct security implications: Azure agents — general-purpose AI solutions running on Azure infrastructure, either hosted by the publisher as a SaaS offering or deployed into the customer's own tenant via container offers. These are suited to cloud-based agentic workflows with custom compute requirements. Microsoft 365 agents — agents integrated directly into Copilot and M365 applications like Teams, Outlook, Word, and Excel. These enhance productivity within the Microsoft 365 environment and are distributed through the Agent Store within the M365 Copilot experience. Marketplace as a governance lever for buyers From the enterprise buyer's perspective, Marketplace isn't just about convenience — it's a governance tool. When an organization acquires an agent through Microsoft Marketplace, it is provisioned and distributed aligned to the organization's existing security and governance standards. This means IT retains control over what gets deployed, to whom, and under what conditions — directly addressing the shadow AI problem discussed earlier. What to Look for When Evaluating Marketplace Agents Not all agents in the Marketplace are equal from a security standpoint. When evaluating third-party agents for enterprise deployment, security leaders should assess: Responsible AI documentation — does the publisher provide transparent records of how the agent was assessed against safety and fairness principles? Data handling disclosures — where is data processed, stored, and for how long? Does it leave your tenant? Offer type architecture — is the agent SaaS-hosted or tenant-deployed, and does that match your data sovereignty requirements? Compliance certifications — does the publisher hold relevant certifications (SOC 2, ISO 27001, regional data protection compliance) that align with your regulatory obligations? The Marketplace's trusted channel doesn't eliminate due diligence — but it does provide a structured, governed starting point that unvetted direct procurement cannot. Trust Is the New Control Plane Behind every efficiency gain, every automated workflow, and every AI-powered product is a human being who needs to trust the system they're relying on. When that trust isn't present, adoption fails — and adoption failure is not a neutral outcome when your competitors are building a more capable AI-powered workforce around you. But trust in this context means more than security compliance. It requires three things: Explainability — the ability to show regulators, customers, and employees how a decision was reached Resilience — the assurance that the system continues to operate safely even when interconnected components fail Inclusivity — confidence that the system produces fair, unbiased outcomes across the full range of people it affects Organizations that embed trust into the foundation of their AI strategy — not as a checkbox, but as a design principle — will hold a structural competitive advantage. Those that treat it as a formality will eventually face what's already playing out: billion-dollar lawsuits over unauthorized data use, regulatory fines for opaque deployment practices, and loss of the customer confidence that makes AI investment worthwhile in the first place. A Practical Starting Point The scope of this challenge can feel overwhelming. The path forward is not. Start here: Establish security fundamentals first — data classification, access management, input sanitization, and output monitoring are non-negotiable foundations Build your governance framework — define agent ownership, document responsibilities, and implement human-in-the-loop checkpoints for decisions that carry real-world consequences Align to regulations proactively — adopt established frameworks, map your full regulatory exposure, and maintain documentation that can be externally verified Invest in AI literacy across the organization — the single biggest barrier to responsible AI adoption is not technology. It is helping people understand how to use these systems well, when to trust them, and when to question them The age of AI agents has arrived. The organizations that lead in this environment will be the ones that treat trust not as a constraint on innovation — but as the foundation it stands on. This post is based on a presentation covering the security, governance, and compliance dimensions of AI in the agentic era. To view the full session recording, visit Security for SDC Series: Securing the Agentic Era Episode 1 For more on Microsoft's Responsible AI principles and Azure AI Foundry, visit Responsible AI: Ethical policies and practices | Microsoft AI. __________________________________________________________________________________________________________________________________________________________________Migrating your AWS offer to Microsoft Marketplace - Network designs
For software development companies looking to expand or replicate their marketplace offerings from AWS to Microsoft Azure, one of the most critical steps in replicating your solution is understanding the right Azure networking capabilities. While AWS and Azure offer similar networking capabilities, key differences in architecture and service offerings can impact the overall solution design. This article provides a comparative overview of the networking services in AWS and Azure, focusing on their unique features and distinctions. By understanding these differences, software companies can make more informed decisions when architecting cloud-native solutions on either platform. The article explores networking services at a high level, with a deeper dive into critical areas such as peering, routing, and elastic load balancing, where the platforms diverge most significantly. Expanding your Marketplace presence to Azure can help software development companies reach a wider customer base. With Azure’s global footprint and diverse cloud users, it offers a powerful platform for increased adoption. This article compares the networking services of AWS and Azure, highlighting their unique features and differences to aid in designing cloud-native solutions. This post is part of a series on replicating apps from AWS to Azure. View all posts in this series. You can also join ISV Success to get access to over $126K USD in cloud credits, AI services, developer tools, and 1:1 technical consults to help you replicate your app and publish to Azure Marketplace. To replicate your app faster get cloud-ready reference code to replicate AWS apps to Azure. To simplify your app replication, understanding how AWS and Azure approach networking—such as routing, connectivity, private access, and hybrid integration—can help you quickly align infrastructure components across clouds. This ensures consistent performance, security, and connectivity for your customers as you extend your offer to Azure. Networking services overview Virtual networks & subnets AWS uses Virtual Private Cloud (VPC) to create isolated networks, spanning all Availability Zones within a region. VPCs support public and private subnets, with VPC peering routing traffic between VPCs using private IPv4 or IPv6 addresses. Azure uses Virtual Networks (VNets), which provide isolation within a region and can span multiple Availability Zones. Azure's VNet peering connects multiple VNets, making them appear as one for connectivity purposes, routing traffic through Microsoft's private network. In AWS, subnets are confined to a specific AZ, while Azure subnets are not tied to a specific Availability Zone. This allows zonal resources to retain their private IPs even when placed in different zones within a region. Peering In AWS and Azure, transitive peering is not natively supported with standard VPC Peering connections. For example, VPC-A and VPC-C cannot communicate directly if they are only peered through VPC-B. To enable transitive routing, AWS offers Transit Gateway, which connects multiple VPCs, allowing traffic between VPC-A and VPC-C. Azure provides Azure Virtual WAN, a centralized hub-and-spoke architecture that simplifies global network connections with built-in transitive routing. VNet Peering uses static routing without BGP, while Azure Virtual WAN supports BGP for branch and ExpressRoute connectivity. Additionally, Azure Virtual WAN now supports BGP for inter-regional hub-to-hub routing, enabling dynamic route propagation across hubs, similar to AWS Transit Gateway peering across regions. See Azure Virtual WAN Pricing for cost considerations. Below is an example of Azure VNet Peering. Traffic management services AWS features Elastic Load Balancing (ELB) with Classic, Application, and Network Load Balancers. Azure has Azure Load Balancer, Azure Application Gateway, and Traffic Manager for load distribution and traffic management. Below is an application of Multi-region load balancing with Traffic Manager, Azure Firewall, and Application Gateway. AWS provides a suite of load balancers including Application Load Balancer (ALB) for Layer 7 traffic, Network Load Balancer (NLB) for high-performance Layer 4 workloads, and Classic Load Balancer (CLB) as a legacy option. These services integrate with a broad set of AWS offerings such as EC2, ECS, and Lambda, and are complemented by Global Accelerator for improving global traffic performance. Azure’s approach to traffic management is more modular. Azure Load Balancer handles Layer 4 traffic and comes in Basic and Standard SKUs for varying scale and resiliency. For Layer 7 scenarios, Azure offers Application Gateway with features like SSL termination and integrated WAF. Azure Front Door adds global Layer 7 load balancing with content acceleration, while Azure Traffic Manager enables DNS-based routing with geo-failover. These services are often used in combination to build resilient architectures, rather than mirroring AWS's load balancer offerings one-to-one. Content delivery and optimization Both AWS and Azure provide robust content delivery network (CDN) services to accelerate the global delivery of content, applications, and APIs. AWS offers CloudFront, a globally distributed CDN service that integrates seamlessly with AWS services, enabling the fast delivery of web content, videos, and APIs to end users. On the Azure side, Azure Front Door acts as a modern, high-performance CDN that also includes advanced load balancing, security features, and seamless integration with Azure services. While both services focus on enhancing global content delivery, Azure Front Door goes a step further by offering enhanced scalability and secure user experiences for content-heavy applications and APIs. Routing & gateways AWS uses route tables associated with subnets in a VPC to direct traffic within and outside the network—for example, toward Internet Gateways, NAT Gateways, or VPN/Transit Gateways. Azure uses User-Defined Routes (UDRs), which can be applied to subnets in a Virtual Network (VNet) and managed centrally via Azure Network Manager. The diagram shows a spoke network group of two VNets accessing a DNS service through a Firewall, where UDRs created by Network Manager make this routing possible. AWS relies on explicit route configurations and services like Transit Gateway for transitive routing across VPCs. Azure creates system routes by default and allows UDRs to customize traffic flow to resources like VPN Gateways, NAT Gateways, or Network Virtual Appliances (NVAs). For internet egress, Azure currently allows implicit SNAT via Standard Public IPs or Load Balancers without outbound rules, but this behavior will be retired on September 30, 2025. After that, outbound access will require explicit configuration using a NAT Gateway, Load Balancer outbound rule, or Azure Firewall. Both platforms provide VPN solutions for hybrid connectivity. AWS supports Site-to-Site VPN for linking on-premises data centers with VPCs, and Client VPN for individual users. Azure offers Site-to-Site (S2S) and Point-to-Site (P2S) VPNs, as well as VNet-to-VNet connections for secure inter-region communication. These VPN services work with their respective routing infrastructures to support secure hybrid and multi-region deployments. DNS services DNS plays a foundational role in service discovery and network communication across both AWS and Azure environments. AWS offers Route 53, a scalable DNS service that supports both public and private hosted zones. It provides features like health checks, weighted routing, and integration with AWS services for domain resolution. Azure delivers similar functionality through Azure DNS for public DNS hosting and Azure Private DNS for internal name resolution within VNets. Azure Private DNS zones can be linked to one or more VNets, enabling seamless name resolution without custom DNS servers. These services are often used alongside load balancers and private endpoints to ensure consistent, secure access to application components. Private connectivity Both AWS and Azure offer dedicated, high-performance private connections to enhance security and reduce latency for hybrid and multi-cloud architectures. AWS provides Direct Connect, which establishes a dedicated network connection from an on-premises data center to AWS. This ensures a more consistent network experience, particularly for workloads requiring low latency or high throughput. Similarly, Azure offers ExpressRoute, a private, dedicated connection from on-premises infrastructure to Azure, bypassing the public internet. These private links typically use technologies like MPLS or Ethernet, depending on the provider and partner, offering better performance and reliability than traditional VPNs. ExpressRoute connections are often used for mission-critical workloads, offering greater reliability, faster speeds, and enhanced security. Security groups and network ACLs Network-level security AWS offers Security Groups (stateful) and Network ACLs (stateless) for network-level security. Security Groups are applied at the instance level, while NACLs work at the subnet boundary, adding an extra layer of filtering. Azure uses Network Security Groups (NSGs) and Application Security Groups (ASGs), which are fully stateful and simplify rule management. NSGs can be applied at both the subnet and network interface level. While Azure lacks a direct equivalent to stateless NACLs, NSGs typically offer enough granularity for most use cases. Azure also offers more granular traffic control with User-Defined Routes (UDRs) and the option to disable "Allow forwarded traffic" in virtual network peering settings. This ensures tight control or blocking of traffic even between peered VNets. Web Application Firewall (WAF) When it comes to Web Application Firewalls, AWS and Azure differ in design and deployment models. AWS WAF can be deployed as a standalone resource and attached to services like CloudFront, API Gateway, or the Application Load Balancer. This offers a high degree of flexibility but may require more hands-on setup and configuration. In contrast, Azure WAF is designed to work in close integration with services such as Application Gateway and Azure Front Door. While not standalone, central WAF policies allow consistent policy reuse across deployments. From a performance perspective, AWS WAF is recognized for its robust application-layer controls and ability to handle high traffic loads efficiently. Azure WAF is often noted for its ease of setup and the depth of its reporting and diagnostics. Private access to PaaS services and Private Endpoints As cloud-native applications increasingly depend on managed services like storage, databases, and messaging queues, securely connecting to these services without exposing traffic to the public internet becomes a critical design consideration. In AWS, VPC Endpoints—available as Interface or Gateway types—allow private connectivity to supported services from within a VPC. Azure provides a similar capability through Private Link, leveraging Private endpoints enabling private access to Azure services such as Azure Storage, SQL Database, or even custom services behind a Load Balancer. Azure Private Link also supports private access to customer or partner services published via Azure Private Link Service. Both approaches improve security posture by keeping traffic on the cloud provider's internal backbone, reducing exposure to external threats. For software development companies building multi-tiered cloud-native applications, these features offer a straightforward way to lock down service-to-service communication without relying on public endpoints. Endpoint policy management In AWS, endpoint management is handled via VPC Endpoint Policies, API Gateway, and AWS PrivateLink. These resource-specific policies are applied to services like S3, DynamoDB, or API Gateway, offering granular control, but requiring more configuration. In contrast, Azure’s endpoint management is more centralized. Services like Azure Application Gateway, Front Door, and Private Endpoint are governed through Network Security Groups (NSGs), Azure Firewall, and WAF policies. Azure's centralized policy enforcement, particularly for Private Endpoints, provides simplified access control and reduces the need for per-service configurations. AWS offers granular control at the cost of additional configuration complexity. Service mesh for Microservices For applications composed of many microservices, managing east-west traffic, enforcing security policies, and gaining observability into service communication can become complex. A service mesh addresses these challenges by abstracting service-to-service communication into a dedicated infrastructure layer. AWS offers App Mesh, which integrates with ECS, EKS, and Fargate, providing features like traffic shifting, retries, circuit breaking, and mTLS encryption. Azure supports service meshes primarily through open-source solutions like Istio and Linkerd, facilitated by managed integrations via the AKs service mesh add-on, simplifying operations on AKS. Additionally, Azure provides Dapr, which complements service mesh by offering higher-level application concerns such as state management, pub/sub messaging and simplified service invocation. For cloud-native software development companies adopting Kubernetes or containerized architectures, a service mesh brings consistency, security, and fine-grained control to internal traffic management. Monitoring and observability Azure Network Watcher provides tools for monitoring, diagnosing, and logging network performance across IaaS resources in Azure. Key features include topology visualization, connection monitoring, and various diagnostic tools like IP flow verification, NSG diagnostics, and packet capture. Additionally, Traffic Analytics provides insights into network traffic patterns. These tools support both hybrid and fully cloud-based network infrastructures, enabling efficient troubleshooting and performance optimization. On the AWS side, VPC Flow Logs and Reachability Analyzer provide comparable visibility and connectivity diagnostics. Key Resources: Microsoft Azure Migration Hub | Microsoft Learn Azure networking documentation Compare AWS and Azure Networking Options - Azure Architecture Center | Microsoft Learn SaaS Workloads - Microsoft Azure Well-Architected Framework | Microsoft Learn Microsoft commercial marketplace documentation Metered billing for SaaS offers in Partner Center Create plans for a SaaS offer in Azure Marketplace Metered billing with Azure Managed Applications Set plan pricing and availability for an Azure Container offer in Microsoft commercial marketplace - Marketplace publisher Configure pricing and availability for a virtual machine offer in Partner Center - Marketplace publisher Get cloud-ready reference code to replicate AWS apps to Azure Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV Success Maximize your momentum with step-by-step guidance to publish and grow your app with App AdvisorPlanning for a quantum future: How to secure data today with Commvault in Microsoft Marketplace
In this guest blog post, Michael Fasulo, Senior Director of Portfolio Marketing at Commvault, discusses how quantum computing will threaten cryptography and how Commvault Cloud in Microsoft Marketplace can help.Zero Trust for Software Development Companies: what “good” looks like in practice
Threats keep accelerating in speed, scale, and sophistication. Microsoft is tracking a sharp rise in daily attacks and password-spray attempts, which is exactly why software development companies need a Zero Trust foundation that assumes breach and limits blast radius by default. The session’s companion deck lays out a crisp, do-first list for software development companies that build and operate multi-tenant apps. I have folded those specifics into this updated post. Start from identity and tenancy If your multi-tenant SaaS lives on Microsoft Entra ID, treat the app’s home tenant like production infrastructure, not a convenience sandbox. Create a dedicated “app tenant” that is locked down, automated, and free of day-to-day human use. Avoid hosting customer-facing multi-tenant app registrations in your corporate tenant where guests, everyday collaboration tools, and broader policies compete with your need for strict controls. Two resources to get your footing fast are the Zero Trust Workshop and the Entra Security guidance. They frame the exact checks below and help you sequence work across identity, device, data, and workload layers. The essential checks most software development companies miss Global admin and subscription access. Global Administrators should not have standing access to Azure subscriptions. Require just-in-time elevation so high-impact operations create signals, slow attacker velocity, and route through observable control points. App creation and lifecycle. Do not allow anyone to create applications or service principals. Restrict that right to a small, audited group, then continuously prune inactive apps, especially those with high Microsoft Graph privileges. Attackers hide behind service principals and abandoned migrations more often than you think. Redirect URIs. Keep reply URLs tight. Only use domains you control. Remove localhost and abandoned cloud sites to cut off token interception and code hijacking paths. Secrets and certificates. Prefer managed identity. If you must use credentials, do not use client secrets. If you must use certificates, keep expirations short and rotate regularly so any compromise has a short half-life. First-party service apps. Ensure Microsoft service applications in your tenant do not have customer-added credentials. Threat actors try to attach their own keys to first-party principals to inherit trusted access. Privileged identities. Keep admin accounts cloud-only to prevent an on-prem compromise from laddering into Entra, and register phishing-resistant methods for every privileged user. Keys or platform authenticators beat OTP fatigue every day of the week. How to roll this out without stalling the roadmap Adopt the workshop mindset. Run a lightweight Zero Trust assessment, pick the items above that are both high-impact and feasible in your environment, and bake them into your next few sprints. Treat security debt like product debt so you always reserve capacity for it. If you are modernizing a legacy app, use that cutover to move the registration to a dedicated app tenant, switch to managed identity, and clean your redirect URIs. The guidance below is what your team will reference as you go. Resources to take the next step Zero Trust Workshop: aka.ms/ztworkshop Entra Security guidance: aka.ms/entra/security If you only do one thing this week, carve out time to separate your app tenant from your corporate tenant, then enforce just-in-time privilege. Those two moves alone shrink your blast radius and make intrusions noisier and easier to catch.AI data governance made easy: How Microsoft Purview tackles GenAI risks and builds trust
As AI transforms software development, the opportunities are vast - but so are the risks. AI promises faster innovation, smarter experiences, and new business models. But behind the excitement, leaders across industries are grappling with a core question: “How do I unlock the benefits of AI while protecting my data, complying with regulations, and maintaining customer trust?” In our 7th episode of the Security for Software Development Companies webinar series - Safeguard Data Security and Privacy in AI-Driven Applications - we addressed this challenge directly. Featuring Microsoft experts Kyle Marsh and Vic Perdana, this session revealed how Microsoft Purview delivers practical, built-in security for AI applications, helping software development companies and enterprise developers meet security expectations from day one. AI security is now a top concern for business leaders The shift toward AI-driven applications has heightened concern among CISOs and decision makers. Recent research from the ISMG First Annual Generative AI Study revealed that: Microsoft Purview for AI: Visibility, control, and compliance by design To address these risks without slowing innovation, Microsoft has extended Purview, our enterprise data governance platform, into the world of AI. From Microsoft Copilot to custom GPT-based assistants, Purview now governs AI interactions, offering: - Data Loss Prevention (DLP) on prompts and responses - Real-time blocking of sensitive content - Audit trails and reporting for AI activity - Seamless integration via Microsoft Graph APIs This means software developers can plug into enterprise-grade governance - with minimal code and no need to reinvent compliance infrastructure. What it looks like: Data Security Posture Management for AI in Microsoft Purview Purview’s Data Security Posture Management (DSPM) for AI offers centralized visibility into all AI interactions across Microsoft Copilot, Azure OpenAI, and even third-party models like Google Gemini or ChatGPT. A developer’s guide: How to integrate AI security using Microsoft Graph APIs Microsoft Purview offers a lightweight, developer-friendly integration path. As Kyle Marsh demonstrated during the webinar, just two core APIs are required: protectionScopes/compute This API lets you determine when and why to submit prompts/responses for review. It returns the execution mode: - evaluateInline: Wait for Purview to approve before sending to the AI model or to the user from the AI model (future functionality) - evaluateOffline: Send in parallel for audit only processContent Use this API to send prompts/responses along with metadata. If a DLP rule is triggered (e.g., presence of a credit card number), the app receives a block instruction before continuing. For less intrusive monitoring, you can use contentActivity, which logs metadata only - ideal for auditing AI usage patterns without exposing user content. Example in action: Blocking confidential data in Microsoft Copilot The power of Purview’s inline protection is demonstrated in Microsoft Copilot. Below, we see how a user’s query surfaced confidential documents - but was blocked from sharing due to policy enforcement. ect Obsidian') - enforced by Microsoft Purview’s DLP policy engine. Built-in support for Microsoft tooling Developers using Copilot Studio, Azure AI Studio, or Azure AI Foundry benefit from built-in or automatic integration: - Copilot Studio: Purview integration is fully automatic - developers don’t need to write a single line of security code. - Azure AI Foundry: Supports evaluateOffline by default; advanced controls can be added via APIs. Custom apps - like a chatbot built with OpenAI APIs - can integrate directly using Microsoft Graph, ensuring enterprise-readiness with minimal effort. Powerful enterprise controls with zero developer overhead Enterprise customers can define and manage AI security policies through the familiar Microsoft Purview interface: - Create custom sensitive info types - Apply role-based access and location targeting - Build blocking or allow-list policies - Conduct audits, investigations, and eDiscovery As a software development company, you don’t need to manage any of these rules. Your app simply calls the API and responds to the decision returned - block, allow, or log. Resources to help you get started Microsoft provides comprehensive tools and docs to help developers integrate AI governance: - Purview Developer Samples: samples - Microsoft Graph APIs for Purview: docs - Web App Security Assessment: aka.ms/wafsecurity - Cloud Adoption Framework: aka.ms/caf - Zero Trust for AI: aka.ms/zero-trust - SaaS Workload Design Principles: docs Final takeaway: Secure AI is smart AI “Securing AI isn’t optional - it’s a competitive advantage. If you want your solution in the hands of enterprises, you must build trust from day one.” With Microsoft Purview and Microsoft Graph, software developers can build AI experiences that are not only intelligent but trustworthy, compliant, and ready for scale. 🎥 Watch the full episode of “Safeguard Data Security and Privacy in AI-Driven Applications” at aka.ms/asiasdcsecurity/recordingNavigating AI security: Identifying risks and implementing mitigations
As artificial intelligence becomes central to software innovation, it also introduces unique security challenges—especially in applications powered by large language models (LLMs). In this edition of the Software Development Company Security Series, we explore the evolving risks facing AI-powered products and share actionable strategies to secure AI solutions throughout the development lifecycle. *Data based on 2024–2025 global reports from Cyberhaven, Swimlane, FS-ISAC, Capgemini, Palo Alto Networks, and Pillar Security analyzing AI security incidents across sectors. Understanding the Evolving AI Threat Landscape AI systems, particularly LLMs, differ from traditional software in one fundamental way: they’re generative, probabilistic, and nondeterministic. This unpredictability opens the door to novel security risks, including: Sensitive Data Exposure: Leaked personal or proprietary data via model outputs. Prompt Injection: Manipulated inputs crafted to subvert AI behavior. Supply Chain Attacks: Risks from compromised training data, open-source models, or third-party libraries. Model Poisoning: Insertion of malicious content during training to bias outcomes. Jailbreaks & Misuse: Circumventing safeguards to produce unsafe or unethical content. Compliance & Trust Risks: Legal, regulatory, and reputational consequences from unvalidated AI outputs. These risks underscore the need for a security-first approach to designing, deploying, and operating AI systems. Key Risks: The OWASP Top 10 for LLMs The OWASP Top 10 LLM Risks offer a framework for understanding threats specific to generative AI. Key entries include: Prompt Injection Sensitive Data Disclosure Model and Data Poisoning Excessive Model Permissions Hallucination & Misinformation System Prompt Leakage Vector Embedding Exploits Uncontrolled Resource Consumption Each of these risks presents opportunities for attackers across the AI lifecycle—from model training and prompt design to output handling and API access. Inherent Risks of LLM-Based Applications Three core attributes contribute to LLM vulnerabilities: Probabilistic Outputs: Same prompt, different results. Non-Determinism: Inconsistent behavior, compounded over time. Linguistic Flexibility: Prone to manipulation and hallucination. Common attack scenarios include: Hallucination: Fabricated content presented as fact—dangerous in domains like healthcare or legal. Indirect Prompt Injection: Malicious prompts hidden in user content (emails, docs). Jailbreaks: Bypassing guardrails using clever or multi-step prompting. Mitigations include retrieval-augmented generation (RAG), output validation, prompt filtering, and user activity monitoring. Microsoft’s Approach to Securing AI Applications Securing AI requires embedding Zero Trust principles and responsible AI at every stage. Microsoft supports this through: Zero Trust Architecture Verify explicitly based on identity and context Use least privilege access controls Assume breach with proactive monitoring and segmentation Shared Responsibility Model Customer-managed models: You manage model security and data. Microsoft-managed platforms: Microsoft handles infrastructure; you configure securely. End-to-End Security Controls Protect infrastructure, APIs, orchestration flows, and user prompts. Enforce responsible AI principles: fairness, privacy, accountability, and transparency. Tools & Ecosystem Microsoft Defender for Cloud: Monitors AI posture and detects threats like credential misuse or jailbreak attempts. Azure AI Foundry: Scans models for embedded risks and unsafe code. Prompt Shield: Filters harmful inputs in real-time. Red Team Tools (e.g., PyRIT): Simulate attacks to harden defenses pre-deployment. Action Steps for Software Companies Securing AI Products Here’s a focused checklist for AI builders and software development companies: Embed Security Early Apply Zero Trust by default Use identity and access management Encrypt data in transit and at rest Leverage Microsoft Security Ecosystem Enable Defender for Cloud for AI workload protection Scan models via Azure AI Foundry Deploy Prompt Shield to defend against jailbreaks and injection attacks Secure the Supply Chain Maintain a Software Bill of Materials (SBOM) Regularly audit and patch dependencies Sanitize external data inputs Mitigate LLM-Specific Risks Validate outputs and restrict unsafe actions Use RAG to reduce hallucination Monitor prompt usage and filter malicious patterns Build for Multi-Tenancy and Compliance Use Well-Architected Framework for OpenAI Isolate tenant data Ensure alignment with data residency and privacy laws Continuously Improve Conduct regular red teaming Monitor AI systems in production Establish incident response playbooks Foster a Security-First Culture Share responsibility across engineering, product, and security teams Train users on AI risks and responsible usage Update policies to adapt to evolving threats Conclusion: Secure AI Is Responsible AI AI’s potential can only be realized when it is both innovative and secure. By embedding security and responsibility across the AI lifecycle, software companies can deliver solutions that are not only powerful—but trusted, compliant, and resilient. Explore More OWASP Top 10 for Large Language Model Applications | OWASP Foundation Overview - AI threat protection - Microsoft Defender for Cloud | Microsoft Learn Prompt Shields in Azure AI Content Safety - Azure AI services | Microsoft Learn AI Red Teaming Agent - Azure AI Foundry | Microsoft Learn AI Trust and AI Risk: Tackling Trust, Risk and Security in AI Models What is Azure AI Content Safety? - Azure AI services | Microsoft Learn Overview of Responsible AI practices for Azure OpenAI models - Azure AI services | Microsoft Learn Architecture Best Practices for Azure OpenAI Service - Microsoft Azure Well-Architected Framework | Microsoft Learn Azure OpenAI Landing Zone reference architecture AI Workload Documentation - Microsoft Azure Well-Architected Framework | Microsoft Learn Announcing new tools in Azure AI to help you build more secure and trustworthy generative AI applications | Microsoft Azure Blog HiddenLayer Model Scanner helps developers assess the security of open models in the model catalog | Microsoft Community Hub Inside AI Security with Mark Russinovich | BRK227 The Price of Intelligence - ACM QueueStart coding in minutes with the Quick-start Development Toolkit
The timeline from an idea for an app to coding is longer than most software development companies would like. Understanding the problem is only the first step in deciding what tools can be used to develop and how to code. And, with a dizzying array of development tools and approaches, time can be lost in consideration before anything is ever built. To help solve this problem, use the Quick-start Development Toolkit — collected actionable resources centered around best practice development patterns — that help software companies get targeted code packages to streamline their app development for AI, Copilot, and agents, AWS to Azure multi-cloud replication, or apps integrating Security. How does it work? As companies brainstorm apps to develop, they often know about the business benefits and purpose, the scenarios where the app would be valuable. What they might not have (without several dev cycles) is the general architecture of that app design and a quick way for their developers to iterate with code, seeing if it’s the right approach. As a result, their time to market may be slower and — when developing apps — this can be costly. With the Quick-start Development Toolkit, we’ve brought together the combined knowledge of experts at Microsoft to provide the foundations of getting developers working with applicable code within minutes: Reference solution architecture: to show how components are used and interact, Click-to-deploy reference code: cloud-ready templates get you coding in minutes, How-to articles: for context to help understand products, patterns, and tips to deploy. These streamlined resources help you and your team get ideas off the drawing board and into a tangible prototype within minutes, saving your team valuable dev cycles. Having access to these should cut time and effort from your dev cycles, helping you stay at the forefront of app development. We look forward to seeing your apps in market! Visit the Quick-start Development Toolkit to boost your code cadence today.Strengthening the software development company supply chain with DevSecOps practices
As cyber threats grow in complexity and frequency, embedding security into the product design lifecycle is no longer optional—it’s essential. In the Microsoft Security for ISV series, our fourth session, “Strengthen the software development company supply chain with DevSecOps practices,” provides in‐depth insights into how software development companies can build robust, secure, and resilient applications while accelerating development processes. By integrating security into every phase—from design to production—software development companies can protect customer data, ensure compliance, and build lasting trust. Understanding the Evolving Threat Landscape According to GitGuardian’s 2024 report, public GitHub repositories saw an alarming surge in hardcoded secrets — with nearly 24 million new secrets (23,770,171) added last year. This represents a 25% increase compared to the previous year and highlights a troubling trend: long-lived plaintext credentials such as API keys, passwords, and authentication tokens continue to proliferate in open-source projects. Despite GitHub’s efforts to filter out known credential patterns during the push process, the rise in generic secrets—which can include common usernames, unstructured passwords, or basic auth strings—remains largely unmitigated, providing attackers of any skill level with an easy entry point and the ability to move laterally within systems. Key Security Strategies for Software Development Companies Embedding Security Throughout the Software Development Lifecycle The evolution of DevSecOps is transforming how organizations approach application security. Michael Friedrich, Cloud Solution Architect at Microsoft, underscored two primary challenges: Growing code bases often come with increased vulnerabilities Developers need intuitive security tooling that doesn’t disrupt productivity DevSecOps is all about “shifting security left” by integrating security practices throughout development—as code is written, built, and deployed—instead of addressing vulnerabilities only after production. This approach not only saves time and resources but also reduces the likelihood of exploiting application-level vulnerabilities. Key strategies include: Early threat modelling to identify and mitigate risks before deployment Collaborative workflows that bring together developers and security teams Continuous scanning methods (static analysis, secret scanning, dependency review) to catch issues early For a deeper dive, explore Microsoft’s Secure Development Lifecycle guide (https://www.microsoft.com/en-us/securityengineering/sdl). Integrating GitHub Advanced Security and Microsoft Defender for Cloud GitHub and Microsoft work in unison for a unified secure development experience. GitHub Advanced Security is embedded directly into the developer workflow to detect vulnerabilities through advanced code scanning (powered by CodeQL), secret scanning, and dependency checks. The integration means that security alerts are provided as developers code—not as an afterthought—which speeds up remediation and reduces production issues. In parallel, Microsoft Defender for Cloud (formerly Defender CSPM) offers a cloud security posture management solution that: Pinpoints and prioritizes risks with a context-aware engine Provides actionable, recommendation-driven insights for DevOps environments Delivers continuous scanning across multi-cloud environments and CI/CD pipelines Learn more about Microsoft Defender for Cloud at https://docs.microsoft.com/en-us/azure/defender-for-cloud and enhance your cloud security posture. The Secure Future Initiative: Secure by Design, Default, and Operations Microsoft’s “Secure Future Initiative” (SFI) is comprehensive framework ensures that security is embedded into every stage of product development and operations through three core principles: Secure by Design Incorporate security during the planning and architecture phases Protect identities and secrets from the start with strong key rotation, hardware security modules, and no hard-coded secrets Secure by Default Enforce robust security configurations so that protection is on by default (for example, MFA enforcement and least privilege access) Secure Operations Establish continuous monitoring protocols, rapid incident response, and centralized security logs Use tools like Microsoft Sentinel for real-time threat analytics These foundational elements ensure that as software development companies develop and scale innovative solutions—including those leveraging artificial intelligence—security remains a steadfast pillar. For additional guidance on Secure Future Initiative, visit https://www.microsoft.com/en-us/trust-center/security/secure-future-initiative Strengthening the Software Development Company Supply Chain with Modern DevSecOps Practices Modern software supply chains often include third-party dependencies, open-source libraries, and automated pipelines. Traditional security measures can’t keep pace with today’s integrated development models. Therefore, it’s critical to: Employ code signing and package verification for third-party components Adopt continuous security scanning using solutions like GitHub’s secret scanning with push protection Integrate Microsoft Defender for DevOps for comprehensive visibility from code to cloud For more on secure supply chain strategies, check out the Secure Supply Chain Consumption Framework (https://www.microsoft.com/en-us/securityengineering/opensource) Real-World Insights from BuildKite and the Role of DevSecOps Guest speaker Ken Thompson, VP of Product at BuildKite, shared practical examples from the front lines of secure continuous integration and delivery. BuildKite’s hybrid model, combining a software-as-a-service control plane with open-source on-premises agents, ensures that sensitive code and secrets never leave a customer’s infrastructure. This design enhances security while enabling: Rapid build times with hyper-parallelized pipelines Integrated security scanning within every build, thereby “shifting left” security Proven practices like the SLSA framework for artifact provenance, which verifies that code and pipelines are built in a trusted manner Ken highlighted examples where Uber have reduced build times from an hour to mere minutes while ensuring every pipeline pass incorporates critical vulnerability scanning. This demonstrates that robust security practices and efficiency can go hand in hand. Taking Action: Strengthening Your Security Posture Today Security is an ongoing journey. By adopting proactive security strategies, embracing DevSecOps practices, and integrating industry-leading tools, software development companies can build resilient, trusted applications that stand up to today’s cyber threats. Action Steps for Software Development Companies: Embed security into every phase of your SDLC Strengthen identity and access with strong MFA, conditional access, and the Zero Trust model Secure secrets using Azure Key Vault and GitHub Advanced Security for automated secret scanning Enhance supply chain security through continuous scanning and vulnerability remediation Monitor your cloud environments with Microsoft Defender for Cloud and Microsoft Sentinel for real-time insights Additional Resources: Microsoft Secure Development Lifecycle – https://www.microsoft.com/en-us/securityengineering/sdl Secure Supply Chain Consumption Framework – https://www.microsoft.com/en-us/securityengineering/opensource Cloud Adoption Framework – https://aka.ms/caf Zero Trust Guidance Center – https://aka.ms/Zero-Trust Start with Security – https://aka.ms/trysecurity SaaS Workload Guidance – https://learn.microsoft.com/en-us/azure/well-architected/saas/ Join ISV Success – https://www.microsoft.com/isvBuilding secure multi-tenant applications with Microsoft Entra ID: A guide for ISVs
In today's rapidly evolving digital landscape, Independent Software Vendors (ISVs) face the significant challenge of developing secure, multi-tenant applications that seamlessly integrate with their customers' existing infrastructure. Microsoft Entra ID offers a robust solution for managing user identities, providing ISVs with tools to enhance security and streamline the user authentication process. In this blog post, we'll explore key security strategies for ISVs and provide additional resources to help you get started. Context As the demand for SaaS applications grows, ISVs must ensure their applications are not only functional but also secure. Multi-tenant applications, which serve multiple customers from a single instance, present unique security challenges. One of the primary concerns is managing user identities securely across different tenants. Microsoft Entra ID addresses these challenges by offering a comprehensive identity management platform that simplifies authentication and authorization while enhancing security. Figure 1 – Single Sign On for seamless user experience Key Security Strategies for ISVs Utilize Microsoft Entra ID for Identity Management Microsoft Entra ID provides a secure, scalable identity management solution that handles user authentication, authorization, and access management. By leveraging Entra ID, ISVs can avoid the complexities and risks associated with building their own identity systems. Adopt Standard Protocols A well-maintained library like MSAL should be the first choice instead of implementing a protocol. Microsoft Entra ID supports industry-standard protocols like OAuth 2.0, OpenID Connect, and SAML, which facilitate secure authentication and authorization. As the last and most expensive choice, ISVs can implement a protocol but must ensure they stay up to date with the protocol. Design for Data Separation In a multi-tenant environment, it is crucial to maintain data separation between tenants to prevent unauthorized access. ISVs should implement robust authorization models and leverage Entra ID's capabilities to ensure data integrity and confidentiality. Become a Verified App Publisher To build trust with customers, ISVs can become verified app publishers. This process involves joining the Microsoft AI Cloud Partner Program and undergoing a vetting process, assuring customers of the application's authenticity and security. Take action: Set up your multitenant identity today For ISVs looking to deepen their understanding of Microsoft Entra ID and its capabilities, here are some valuable resources: Microsoft Entra ID Documentation – Explore comprehensive guides and tutorials on implementing Entra ID in your applications. Microsoft Identity Platform Developer Guide – Learn how to integrate authentication and authorization into applications. aka.ms/UpcomingIDLOBDev - Curated content for Microsoft Identity platform training workshops By adopting these strategies and utilizing the resources provided, ISVs can build secure, scalable, and efficient multi-tenant applications that meet the growing demands of their customers. Embracing Microsoft Entra ID not only enhances security but also simplifies the development process, allowing ISVs to focus on delivering innovative solutions. Want to learn more: 📅 Join our ISV Security sessions to stay updated on the latest best practices 🔗 Subscribe to Azure Security Updates for continuous learning 📞 Connect with your Microsoft account representative for tailored security guidance Let’s work together to build a more secure digital future. 🚀Designing secure and resilient ISV applications
Understanding the evolving security landscape Cyber threats have increased fivefold in the past year, with organizations facing: 340 million nation-state cyberattacks daily A rise in password attacks from 4,000 to 7,000 per second Over 1,500 tracked threat actors, up from 300 in 2023 With the growing sophistication of adversaries, prioritizing security is no longer optional—it’s a necessity. ISVs must take proactive measures to safeguard their applications and services. Figure 1- Cyber threats in the Era of AI Key security strategies for ISVs 1. Embed security into product design Security should be an integral part of the software development lifecycle (SDLC), not an afterthought. By incorporating secure design principles early, ISVs can reduce costs and risks associated with vulnerabilities. Perform threat modeling to identify risks before development Use secure coding frameworks and avoid custom-built security controls Implement the Zero Trust model, assuming no implicit trust for users, devices, or applications 📌 Explore: Microsoft Secure Development Lifecycle guide 2. Strengthen identity and access controls Identity remains the primary security perimeter. Implement strong authentication and authorization mechanisms to protect user accounts. Enforce Multi-Factor Authentication (MFA) to block 90% of cyberattacks Use conditional access policies to limit access based on risk signals Adopt least privilege principles to restrict access to necessary resources 📌 Start with: Identity and Access Management in Azure guide 3. Secure secrets and credentials One of the most common security mistakes is hardcoding credentials in source code. Instead: Store secrets securely using Azure Key Vault Implement automated secret scanning to detect exposed credentials Rotate secrets regularly and avoid long-lived access tokens 📌 Check: GitHub Advanced Security for automated secret scanning 4. Adopt a Zero Trust architecture Traditional perimeter-based security is no longer sufficient. The Zero Trust model ensures continuous verification across: Identities – Enforce strong authentication and least privilege access Devices – Assess compliance before granting access Applications & Data – Restrict access based on risk levels 📌 Learn more: Zero Trust Guidance Center 5. Ensure secure supply chain practices Many security breaches originate from compromised third-party dependencies. Strengthen your software supply chain security by: Using code signing and package verification for all dependencies Scanning for vulnerabilities in third-party libraries Implementing DevSecOps pipelines to automate security checks 📌 Read: Secure Supply Chain Consumption Framework 6. Protect against AI-specific threats AI-powered applications introduce new attack vectors, including prompt injection, model poisoning, and adversarial manipulation. Mitigate these risks by: Using responsible AI principles to minimize unintended biases and risks Applying AI safety measures, such as Azure AI Content Safety Restricting access to models and validating input/output integrity 📌 Discover: Microsoft Responsible AI Guidelines 7. Monitor and respond to security threats Effective threat detection and incident response are essential for minimizing damage from cyberattacks. Use Microsoft Sentinel for real-time security monitoring Automate threat detection with Defender for Cloud Establish an incident response plan to quickly contain and mitigate breaches 📌 Explore: Microsoft Defender for Cloud _________________________________________________________________________________________ Take action: strengthen your security posture today Security is an ongoing journey. By adopting proactive security strategies, ISVs can build resilient, trusted applications that safeguard customers and drive long-term success. 🔹 Want to learn more? 📅 Join our ISV Security sessions to stay updated on the latest best practices 🔗 Subscribe to Azure Security Updates for continuous learning 📞 Connect with your Microsoft account representative for tailored security guidance Let’s work together to build a more secure digital future. 🚀 __________________________________________________________________________________________ Additional resources To embed your security when you design your applications, explore these key resources: Security Development Lifecyle: https://www.microsoft.com/en-us/securityengineering/sdl Secure Supply Chain Consumption Framework: https://www.microsoft.com/en-us/securityengineering/sdl/s2c2f Cloud Adoption Framework: https://aka.ms/caf Zero Trust: https://aka.ms/Zero-Trust Adopt Security: https://aka.ms/trysecurity SaaS Workload: https://learn.microsoft.com/en-us/azure/well-architected/saas/ Join ISV Success: www.microsoft.com/isv
