Securing AI apps and agents on Microsoft Marketplace
Why security must be designed in—not validated later AI apps and agents expand the security surface beyond that of traditional applications. Prompt inputs, agent reasoning, tool execution, and downstream integrations introduce opportunities for misuse or unintended behavior when security assumptions are implicit. These risks surface quickly in production environments where AI systems interact with real users and data. Deferring security decisions until late in the lifecycle often exposes architectural limitations that restrict where controls can be enforced. Retrofitting security after deployment is costly and can force tradeoffs that affect reliability, performance, or customer trust. Designing security early establishes clear boundaries, enables consistent enforcement, and reduces friction during Marketplace review, onboarding, and long‑term operation. In the Marketplace context, security is a foundational requirement for trust and scale. This post is part of a series on building and publishing well-architected AI apps and Agents on Microsoft Marketplace. How AI apps and agents expand the attack surface Without a clear view of where trust boundaries exist and how behavior propagates across systems, security controls risk being applied too narrowly or too late. AI apps and agents introduce security risks that extend beyond those of traditional applications. AI systems accept open‑ended prompts, reason dynamically, and often act autonomously across systems and data sources. These interaction patterns expand the attack surface in several important ways: New trust boundaries introduced by prompts and inputs, where unstructured user input can influence reasoning and downstream actions Autonomous behavior, which increases the blast radius when authentication or authorization gaps exist Tool and integration execution, where agents interact with external APIs, plugins, and services across security domains Dynamic model responses, which can unintentionally expose sensitive data or amplify errors if guardrails are incomplete Each API, plugin, or external dependency becomes a security choke point where identity validation, audit logging, and data handling must be enforced consistently—especially when AI systems span tenants, subscriptions, or ownership boundaries. Using OWASP GenAI Top 10 as a threat lens The OWASP GenAI Top 10 provides a practical, industry‑recognized lens for identifying and categorizing AI‑specific security threats that extend beyond traditional application risks. Rather than serving as a checklist, the OWASP GenAI Top 10 helps teams ask the right questions early in the design process. It highlights where assumptions about trust, input handling, autonomy, and data access can break down in AI‑driven systems—often in ways that are difficult to detect after deployment. Common risk categories highlighted by OWASP include: Prompt injection and manipulation, where malicious input influences agent behavior or downstream actions Sensitive data exposure, including leakage through prompts, responses, logs, or tool outputs Excessive agency, where agents are granted broader permissions or action scope than intended Insecure integrations, where tools, plugins, or external systems become unintended attack paths Highly regulated industries, sensitive data domains, or mission‑critical workloads may require additional risk assessment and security considerations that extend beyond the OWASP categories. The OWASP GenAI Top 10 allows teams to connect high‑level risks to architectural decisions by creating a shared vocabulary that sets the foundation for designing guardrails that are enforceable both at design time and at runtime. Designing security guardrails into the architecture Security guardrails must be designed into the architecture, shaping where and how policies are enforced, evaluated, and monitored throughout the solution lifecycle. Guardrails operate at two complementary layers: Design time, where architectural decisions determine what is possible, permitted, or blocked by default Runtime, where controls actively govern behavior as the AI app or agent interacts with users, data, and systems When architectural boundaries are not defined early, teams often discover that critical controls—such as input validation, authorization checks, or action constraints—cannot be applied consistently without redesign: Tenancy boundaries, defining how isolation is enforced between customers, environments, or subscriptions Identity boundaries, governing how users, agents, and services authenticate and what actions they can perform Environment separation, limiting the blast radius of experimentation, updates, or failures Control planes, where configuration, policy, and behavior can be adjusted without redeploying core logic Data planes, controlling how data is accessed, processed, and moved across trust boundaries Designing security guardrails into the architecture transforms security from reactive to preventative, while also reducing friction later in the Marketplace journey. Clear enforcement boundaries simplify review, clarify risk ownership, and enable AI apps and agents to evolve safely as capabilities and integrations expand. Identity as a security boundary for AI apps and agents Identity defines who can access the system, what actions can be taken, and which resources an AI app or agent is permitted to interact with across tenants, subscriptions, and environments. Agents often act on behalf of users, invoke tools, and access downstream systems autonomously. Without clear identity boundaries, these actions can unintentionally bypass least‑privilege controls or expand access beyond what users or customers expect. Strong identity design shapes security in several key ways: Authentication and authorization, determines how users, agents, and services establish trust and what operations they are allowed to perform Delegated access, constraints agents to act with permissions tied to user intent and context Service‑to‑service trust, ensures that all interactions between components are explicitly authenticated and authorized Auditability, traces actions taken by agents back to identities, roles, and decisions A zero-trust approach is essential in this context. Every request—whether initiated by a user, an agent, or a backend service—should be treated as untrusted until proven otherwise. Identity becomes the primary control plane for enforcing least privilege, limiting blast radius, and reducing downstream integration risk. This foundation not only improves security posture, but also supports compliance, simplifies Marketplace review, and enables AI apps and agents to scale safely as integrations and capabilities evolve. Protecting data across boundaries Data may reside in customer‑owned tenants, subscriptions, or external systems, while the AI app or agent runs in a publisher‑managed environment or a separate customer environment. Protecting data across boundaries requires teams to reason about more than storage location. Several factors shape the security posture: Data ownership, including whether data is owned and controlled by the customer, the publisher, or a third party Boundary crossings, such as cross‑tenant, cross‑subscription, or cross‑environment access patterns Data sensitivity, particularly for regulated, proprietary, or personally identifiable information Access duration and scope, ensuring data access is limited to the minimum required context and time When these factors are implicit, AI systems can unintentionally broaden access through prompts, retrieval‑augmented generation, or agent‑initiated actions. This risk increases when agents autonomously select data sources or chain actions across multiple systems. To mitigate these risks, access patterns must be explicit, auditable, and revocable. Data access should be treated as a continuous security decision, evaluated on every interaction rather than trusted by default once a connection exists. This approach aligns with zero-trust principles, where no data access is implicitly trusted and every request is validated based on identity, context, and intent. Runtime protections and monitoring For AI apps and agents, security does not end at deployment. In customer environments, these systems interact continuously with users, data, and external services, making runtime visibility and control essential to a strong security posture. AI behavior is also dynamic: the same prompt, context, or integration can produce different outcomes over time as models, data sources, and agent logic evolve, so monitoring must extend beyond infrastructure health to include behavioral signals that indicate misuse, drift, or unintended actions. Effective runtime protections focus on five core capabilities: Vulnerability management, including regular scanning of the full solution to identify missing patches, insecure interfaces, and exposure points Observability, so agent decisions, actions, and outcomes can be traced and understood in production Behavioral monitoring, to detect abnormal patterns such as unexpected tool usage, unusual access paths, or excessive action frequency Containment and response, enabling rapid intervention when risky or unauthorized behavior is detected Forensics readiness, ensuring system-state replicability and chain-of-custody are retained to investigate what happened, why it happened, and what was impacted Monitoring that only tracks availability or performance is insufficient. Runtime signals must provide enough context to explain not just what happened, but why an AI app or agent behaved the way it did, and which identities, data sources, or integrations were involved. Equally important is integration with broader security event and incident management workflows. Runtime insights should flow into existing security operations so AI-related incidents can be triaged, investigated, and resolved alongside other enterprise security events—otherwise AI solutions risk becoming blind spots in a customer’s operating environment. Preparing for incidents and abuse scenarios No AI app or agent operates in a perfectly controlled environment. Once deployed, these systems are exposed to real users, unpredictable inputs, evolving data, and changing integrations. Preparing for incidents and abuse scenarios is therefore a core security requirement, not a contingency plan. AI apps and agents introduce unique incident patterns compared to traditional software. In addition to infrastructure failures, teams must be prepared for prompt abuse, unintended agent actions, data exposure, and misuse of delegated access. Because agents may act autonomously or continuously, incidents can propagate quickly if safeguards and response paths are unclear. Effective incident readiness starts with acknowledging that: Abuse is not always malicious, misuse can stem from ambiguous prompts, unexpected context, or misunderstood capabilities Agent autonomy may increase impact, especially when actions span multiple systems or data sources Security incidents may be behavioral, not just technical, requiring interpretation of intent and outcomes Preparing for these scenarios requires clearly defined response strategies that account for how AI systems behave in production. AI solutions should be designed to support pause, constrain, or revoke agent capabilities when risk is detected, and to do so without destabilizing the broader system or customer environment. Incident response must also align with customer expectations and regulatory obligations. Customers need confidence that AI‑related issues will be handled transparently, proportionately, and in accordance with applicable security and privacy standards. Clear boundaries around responsibility, communication, and remediation help preserve trust when issues arise. How security decisions shape Marketplace readiness From initial review to customer adoption and long‑term operation, security posture is a visible and consequential signal of readiness. AI apps and agents with clear boundaries—around identity, data access, autonomy, and runtime behavior—are easier to evaluate, onboard, and trust. When security assumptions are explicit, Marketplace review becomes more predictable, customer expectations are clearer, and operational risk is reduced. Ambiguous trust boundaries, implicit data access, or uncontrolled agent actions can introduce friction during review, delay onboarding, or undermine customer confidence after deployment. Marketplace‑ready security is therefore not about meeting a minimum bar. It is about enabling scale. Well-designed security allows AI apps and agents to integrate into enterprise environments, align with customer governance models, and evolve safely as capabilities expand. When security is treated as a first‑class architectural concern, it becomes an enabler rather than a blocker—supporting faster time to market, stronger customer trust, and sustainable growth through Microsoft Marketplace. What’s next in the journey Security for AI apps and agents is not a one‑time decision, but an ongoing design discipline that evolves as systems, data, and customer expectations change. By establishing clear boundaries, embedding guardrails into the architecture, and preparing for real‑world operation, publishers create a foundation that supports safe iteration, predictable behavior, and long‑term trust. This mindset enables AI apps and agents to scale confidently within enterprise environments while meeting the expectations of customers adopting solutions through Microsoft Marketplace. Key resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor, Quick-Start Development Toolkit Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessHow do you actually unlock growth from Microsoft Teams Marketplace?
Hey folks 👋 Looking for some real-world advice from people who’ve been through this. Context: We’ve been listed as a Microsoft Teams app for several years now. The app is stable, actively used, and well-maintained - but for a long time, Teams Marketplace wasn’t a meaningful acquisition channel for us. Things changed a bit last year. We started seeing organic growth without running any dedicated campaigns, plus more mid-market and enterprise teams installing the app, running trials, and even using it in production. That was encouraging - but it also raised a bigger question. How do you actually systematize this and get real, repeatable benefits from the Teams Marketplace? I know there are Microsoft Partner programs, co-sell motions, marketplace benefits, etc. - but honestly, it’s been very hard to figure out: - where exactly to start - what applies to ISVs building Teams apps - how to apply correctly - and what actually moves the needle vs. what’s just “nice to have” On top of that, it’s unclear how (or if) you can interact directly with the Teams/Marketplace team. From our perspective, this should be a win-win: we invest heavily into the platform, build for Teams users, and want to make that experience better. Questions to the community: If you’re a Teams app developer: what actually worked for you in terms of marketplace growth? Which Partner programs or motions are worth the effort, and which can be safely ignored early on? Is there a realistic way to engage with the Teams Marketplace team (feedback loops, programs, office hours, etc.)? How do you go from “organic installs happen” to a structured channel? Would really appreciate any practical advice, lessons learned, or even “what not to do” stories 🙏 Thanks in advance!Marketplace sales are never showing as "Won"
I was looking through the Insights page of the Partner Portal today and I came across a weird quirk of the way Marketplace sales are reported. None of our Azure Marketplace Leads (the leads & sales we get from customers buying our solutions from the Azure Marketplace) are showing up as "Won". On the https://partner.microsoft.com/en-us/dashboard/opportunities/referral/cohort, under "Business performance" we see that Won rate, Lost rate, and Value won all are missing the customers we've gotten through the marketplace. It only appears to be showing manually entered co-sell leads. This seems to be messing pretty heavily with our cohort generation/analysis as we're placed into the incorrect tier. (Sidenote: are cohorts only generated once a year?) Under the https://partner.microsoft.com/en-us/dashboard/opportunities/referral/leads for the "Marketplace leads" tab I'm also seeing 0 "Won" and 0 "Won value" for all of our Marketplace Offers. They get stuck under "Leads" without progressing forward. Is there a way I'm missing to mark our Marketplace Leads as "Won"? We have a bunch of leads that I'd like to reflect in the tool properly.5 App Advisor capabilities that help sell faster on Microsoft Marketplace
Signing in to App Advisor unlocks features that help you manage projects, personalize your development guidance, and move from build to Marketplace sales faster. App Advisor helps streamline the process for anyone, with no barriers to start. However, when you sign in and authenticate, the experience becomes even more powerful. Read the 5 reasons to authenticate in App Advisor here.
SaaS Transactable Listing on Microsoft Marketplace — Questions & Best Practices
Hi Microsoft Marketplace Community, We are Saturam Inc., the team behind Qualdo-DRX — a Data Observability, Reliability & Quality SaaS solution now listed on the Microsoft Azure Marketplace. As we continue to build and optimize our Marketplace presence, we have a few questions and would love to hear from experienced partners and the Microsoft team. Qualdo-DRX is a Managed Application offer on Azure Marketplace. We help enterprises monitor data quality, reliability, and observability across Azure-native data services including Microsoft Fabric, Azure Synapse, ADLS, and more. A free trial plan is also available. We are interested in connecting with other ISVs who have successfully published transactable SaaS offers and navigated the Microsoft Marketplace journey. If you have lessons learned, tips, or resources to share, we welcome the conversation! Feel free to reply below or reach out directly. We are happy to share our own experience listing Qualdo-DRX and support others on their Marketplace journey. #AzureMarketplace #SaaS #TransactableOffer #ISV #MicrosoftMarketplace #CoSell #MarketplaceRewardsIssues with Support
Hi we have been a partner for years, but lately there has been some issues with our account we have a few support tickets and the tickets stay open with no activity, we also tried to get our partner manager to help, (we got a new one this Jan) and they could/did not do anything either, just wanted to check with the community if y'all had any advice on this and how we can get this escalated since some of the tickets do have some business impact to our day to day businessMigrating your AWS offer to Microsoft Marketplace - Identity and Access Management (IAM)
As a software development company, expanding your marketplace presence beyond AWS Marketplace to include Microsoft Marketplace can open new doors to grow your customer base. Azure’s broad ecosystem and diverse user base offer a dynamic platform to enhance your application’s reach and potential. This post is part of a series on replicating apps from AWS to Azure. View all posts in this series. Expand your reach and accelerate growth by bringing your AWS-based app to Azure and selling through Microsoft Marketplace. This guide will break down key IAM differences between AWS and Microsoft Entra ID, helping you replicate your app’s identity management quickly and securely. Future posts will dive deeper into specific IAM configurations and best practices. 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 Marketplace. To ensure a smooth app replication, start by understanding the key differences between AWS IAM and Microsoft Entra ID. A clear grasp of these distinctions will help you transition identity management effectively while optimizing security and performance on Azure. This guide will highlight these differences, map comparable services, and provide actionable steps for a seamless IAM replication. This article addresses Identity and Access Management (IAM) and select Identity Services: Amazon Cognito vs. Microsoft Entra ID. Identity and Access management (IAM) Identity and Access Management (IAM) is essential for securing and managing who can access resources, under what conditions, and with what specific permissions. AWS and Azure both offer robust IAM solutions to manage identities, roles, and policies, but they differ significantly in architecture, integration capabilities, and ease of use, particularly for software companies building SaaS solutions migrating from AWS to Azure. Users, Groups, and Roles AWS IAM creates users within an AWS account, grouping them into IAM User Groups, while Azure IAM manages users as directory objects in Microsoft Entra ID, assigning permissions via Azure RBAC. Both support MFA and identity federation through SAML, Azure enforcing Conditional Access based on location, device state, and user risk. AWS IAM grants permissions using JSON-based policies, allowing roles to be assumed by users, AWS services, or external identities without permanent credentials. Azure IAM assigns permissions via RBAC to users, groups, and service principals, offering predefined and customizable roles. Azure supports federated identity for hybrid environments, while Azure integrates with on-premises Microsoft Entra ID. Permissions and Policies AWS IAM employs JSON-based policies for granular permissions across AWS services. Policies can be identity-based, directly attached to users or roles, or resource-based, applied directly to resources such as S3 buckets or DynamoDB tables. AWS supports temporary credentials via roles, which can be assumed by users, AWS services, or external federated identities. Azure RBAC leverages predefined roles (e.g., Global Administrator, Contributor, Reader) or custom roles, offering clear hierarchical permissions management across resource, resource group, subscription, or management group levels. AWS also allows conditional permissions through advanced policy conditions (e.g., IP address, MFA status, tags). Azure IAM employs Conditional Access Policies, adjusting access based on location, device state, and user risk. AWS IAM grants access only when explicitly allowed, whereas Azure IAM evaluates role assignments and conditions before permitting actions. For multi-account and cross-tenant access, AWS IAM enables secure cross-account roles, while Azure IAM supports External Identities for inter-tenant collaboration. AWS IAM delegates administrative rights using roles and policies, whereas Azure IAM assigns administrative roles within organizations for delegated management. AWS IAM enables controlled, temporary access to S3 objects using pre-signed URLs, which grant time-limited access to specific resources without modifying IAM policies. These URLs are often used for secure file sharing and API integrations. In Azure, a similar concept exists with Shared Access Signatures (SAS) Keys, which provide scoped and time-limited access to Azure Storage resources like Blob Storage, Table Storage, and Queues. Unlike pre-signed URLs, SAS keys allow granular control over permissions, such as read, write, delete, or list operations, making them more flexible for temporary access Integration with External Identities Both platforms provide Single Sign-On (SSO). AWS IAM uses AWS SSO. Microsoft Entra ID also supports SSO with SAML, OAuth, and OIDC. For federated identities, AWS IAM allows external users to assume roles, while Microsoft Entra ID assigns roles based on its access model. Hybrid environments are supported through on-premises directory integration. AWS IAM connects to Active Directory via AWS Directory Service, while Microsoft Entra ID integrates with on-prem AD using Microsoft Entra ID Connect, enabling hybrid identity management and SSO for cloud and on-prem resources. Both support automated user provisioning: AWS IAM utilizes AWS SSO and federation services, while Microsoft Entra ID supports SCIM 2.0 for third-party applications and syncs on-prem AD via Entra ID Connect. AWS IAM enables ECS, EKS, and Lambda workloads to pull container images from Amazon Elastic Container Registry (ECR) using IAM roles. These roles grant temporary permissions to fetch container images without requiring long-term credentials. In Azure, Azure Container Registry (ACR) authentication is managed through Service Principals and Managed Identities. Instead of IAM roles, Azure applications authenticate using Entra ID, allowing containers to securely pull images from ACR without embedding credentials. Access Control Models AWS IAM uses a policy-based access model, where permissions are defined in JSON policies attached to users, groups, or roles. In contrast, Azure separate's identity management via Microsoft Entra ID from access management via Azure RBAC, which assigns roles to users, groups, service principals, or managed identities to control access to Azure resources. Both provide fine-grained access control. AWS IAM sets permissions at the resource level (e.g., EC2, S3), while Azure uses Azure RBAC to assign Microsoft Entra ID identities roles that apply hierarchically at the resource, subscription, or management group levels. Both follow a default "deny" model, granting access only when explicitly allowed. For multi-account and multi-tenant support, AWS IAM enables cross-account roles. Microsoft Entra organizations can use External ID cross-tenant access settings to manage collaboration with other Microsoft Entra organizations and Microsoft Azure clouds through B2B collaboration and B2B direct connect. Delegation is managed through IAM roles in AWS and RBAC role assignments in Azure. Conditional access is supported—AWS uses policy-based conditions (e.g., time-based, IP restrictions), while Microsoft Entra ID relies on Conditional Access Policies (e.g., location, device health, risk level). AWS allows cross-account policy sharing, while Microsoft Entra ID enables role-based delegation at different organizational levels. Both support cross-service permissions, AWS IAM policies can define access across multiple AWS services, while Azure uses Azure RBAC to assign Microsoft Entra ID identities permissions across Azure services such as Blob Storage, SQL Database, and Key Vault. For workload authentication, AWS IAM roles provide temporary credentials for EC2, Lambda, and ECS, eliminating hardcoded secrets. In Azure, Microsoft Entra ID enables Managed Identities, allowing applications running on Azure services to authenticate securely to other Azure resources without managing credentials. Additionally, Microsoft Entra Workload Identities allow Kubernetes workloads—especially on AKS—to authenticate using Entra ID via OpenID Connect (OIDC), streamlining access to Azure services in containerized and multi-tenant environments. In AWS, containerized workloads such as ECS, EKS, and Lambda use IAM roles to securely authenticate and pull images from Amazon ECR, avoiding hardcoded credentials. In Azure, containerized applications authenticate to Azure Container Registry (ACR) using Microsoft Entra ID identities—either Managed Identities or Service Principals. Permissions such as AcrPull are granted via Azure RBAC, enabling secure image access. Azure’s model supports cross-tenant authentication, making it particularly useful for ISVs with multi-tenant containerized SaaS deployments. Cross-account storage access in AWS uses IAM roles and bucket policies for Amazon S3, allowing external AWS accounts to securely share data. In Azure, Microsoft Entra ID B2B and RBAC assignments. This model avoids the need to share credentials or manage access via SAS tokens, streamlining collaborations in multi-tenant environments. Audit and Monitoring AWS IAM and Microsoft Entra ID both provide robust audit logging and monitoring. AWS CloudTrail logs IAM and AWS API calls for 90 days by default, with extended retention via CloudTrail Lake or Amazon S3. Microsoft Entra ID logs sign-ins, including failed attempts, retaining data for 7 days in the free tier and up to 30 to 90 days in Premium tiers. For longer retention, Log Analytics or Sentinel should be used. For real-time monitoring, AWS CloudWatch tracks IAM activities like logins and policy changes, while Microsoft Entra ID Premium does so via Azure AD Identity Protection. AWS uses CloudWatch Alarms for alerts on permission changes, whereas Microsoft Entra ID alerts on suspicious sign-ins and risky users. AWS GuardDuty detects IAM threats like unusual API calls or credential misuse, while Microsoft Entra ID’s Identity Protection identifies risky sign-ins (Premium P2 required). AWS Security Hub aggregates findings from CloudTrail and GuardDuty, while Microsoft Entra ID integrates with Azure Sentinel for advanced security analytics. For IAM configuration tracking, AWS Config monitors policies and permissions, while Microsoft Entra ID’s Audit Log track's role, group, and user changes. AWS Artifact provides downloadable compliance reports. Microsoft Purview Compliance Manager enables customers to assess and manage their compliance across services like Entra ID and Azure using built-in control assessments. AWS CloudTrail logs IAM activity across AWS Organizations, and Microsoft Entra ID Premium supports cross-tenant access monitoring. Azure Lighthouse enables cross-tenant management for service providers, integrating with Microsoft Entra ID for delegated access without guest accounts. It applies RBAC across tenants and manages shared resources like Azure Blob Storage and virtual machines, streamlining ISV operations in marketplace scenarios. Pricing AWS IAM and Microsoft Entra ID provide core IAM services for free, with advanced features available in paid tiers. Both platforms support unlimited users for basic IAM functions, with AWS offering free user, role, and policy creation, while Microsoft Entra ID allows up to 500,000 objects (users/groups) at no cost. Additional users can be added for free, though advanced features require a paid plan. MFA is free on both platforms, but Microsoft Entra ID includes advanced MFA options in Premium tiers. AWS does not have risk based Conditional Access for free. Microsoft Entra ID includes it in Premium P1/P2 tiers (starting at $6 per user/month) Custom policies for fine-grained access control are free in AWS and Azure. Identity federation is free in AWS IAM, while Microsoft Entra ID requires a Premium P1/P2 plan. Microsoft Entra ID includes Self-Service Password Reset (SSPR) in Premium P1/P2, whereas AWS IAM does not offer it for free. Both platforms support RBAC at no extra cost. Directory synchronization is available via Microsoft Entra ID Premium P1/P2. AWS Directory Service is a paid managed AD service, not part of IAM. AWS IAM doesn’t have a direct “guest user” concept; instead, you configure federated access or cross-account roles, but Microsoft Entra ID requires a Premium tier for Azure AD External Identities. Full API and CLI access for user, policy, and role management is free on both platforms. Advanced security monitoring is available through AWS GuardDuty and Security Hub at an extra cost. Microsoft Entra ID provides advanced security monitoring, such as risk-based conditional access, within Premium P1/P2 tiers. Both platforms offer free support for service principals, enabling secure application access and role assignments. Amazon Cognito vs. Microsoft Entra ID Amazon Cognito provides identity and access management for applications in AWS, while Azure offers this through Microsoft Entra ID, centralizing IAM tools for ISVs. Both differ in authentication, integration, and target audiences. User management Amazon Cognito uses User Pools for authentication and Identity Pools for federated identities. Microsoft Entra ID serves as a central identity directory for Azure, Microsoft 365, and third-party apps, integrating with on-prem AD. Authentication methods Both support password-based login, MFA, passwordless authentication, and social sign-in. Amazon Cognito can be extended to support passwordless authentication with magic links, OTPs, and FIDO2 using AWS Lambda. Microsoft Entra ID supports native passwordless options like FIDO2, Windows Hello, and OTPs, plus risk-based conditional authentication. Identity Federation & SSO Amazon Cognito supports SAML, OAuth 2.0, and OIDC. Microsoft Entra ID offers enterprise SSO with SAML, OAuth, and WS-Federation, plus cross-tenant federation via Entra ID B2B. Access Control & Security Policies AWS relies on AWS IAM and custom logic for built-in RBAC or Attribute Based Access Control (ABAC). Microsoft Entra ID includes RBAC, ABAC, and Conditional Access Policies for granular security control. Self-Service & User Management Amazon Cognito allows self-registration and password resets, with workflow customization via AWS Lambda. Microsoft Entra ID offers SSPR, access reviews, and an enterprise portal for account management. Security & Compliance Amazon Cognito provides monitoring via AWS CloudTrail and GuardDuty, compliant with HIPAA, GDPR, and ISO 27001. Microsoft Entra ID integrates with Microsoft Defender for Identity for threat detection, with compliance for HIPAA, GDPR, ISO 27001, and FedRAMP, plus risk-based authentication in premium tiers. Migration best practices tips When migrating IAM from AWS to Azure, organizations should: Assess existing AWS IAM policies and roles, mapping them carefully to Azure RBAC roles. Leverage Microsoft Entra Connect for seamless integration with existing on-premises Active Directory environments. Use Azure's Managed Identities and SAS tokens strategically to minimize credential management complexity. Implement Conditional Access Policies in Azure to dynamically secure and simplify access management. Key Resources: Microsoft Azure Migration Hub | Microsoft Learn Publishing to commercial marketplace documentation Pricing Calculator | Microsoft Azure Azure IAM best practices Configure SAML/WS-Fed identity provider - Microsoft Entra External ID Maximize your momentum with step-by-step guidance to publish and grow your app with App Advisor Accelerate your development with cloud ready deployable code through the Quick-start Development ToolkitSharePoint Embedded security features: A comprehensive Q&A guide
🔐 Authentication & identity management Q: How does SharePoint Embedded integrate with Microsoft Entra ID? A: SharePoint Embedded requires all users to authenticate through Microsoft Entra ID Single sign-on (SSO): Seamless authentication across Microsoft 365 services Multi-factor authentication (MFA): Configurable per-organization security policies Guest access: Secure B2B collaboration using Entra ID B2B guest accounts Key requirement: All users accessing SharePoint Embedded containers must exist as either: Member users in your Entra ID tenant Guest users invited through Entra ID B2B collaboration Q: What's the difference between delegated and application permissions? A: Understanding these permission models is critical for security and auditability: Delegated permissions (recommended): Application acts on behalf of an authenticated user User context preserved in audit logs Users must authenticate before accessing containers Enables file search capabilities within containers Use case: Interactive applications where user identity matters Application-only permissions (restricted Use): Application acts without user context No user tracking in audit logs (shows as application) Search capabilities are limited Use case: Background jobs, system integrations, automated processes Best practice: Use delegated permissions whenever possible to maintain proper audit trails and security accountability. Q: How do we secure service principals and application secrets? A: SharePoint Embedded supports multiple secure authentication methods: Managed identities (Most Secure): No secrets or certificates to manage Identity tied to Azure resources Cannot be used outside your Azure environment Eliminates credential exposure risk Certificate-based authentication: More secure than client secrets Longer validity periods Can be stored in Azure Key Vault Client secrets (use with caution): Store in Azure Key Vault, never in code or config files Enable automatic rotation (recommended: 90-day rotation) Configure expiration alerts Security hardening: Apply Conditional Access policies to service principals Restrict to corporate IP ranges using Named Locations Implement Privileged Identity Management (PIM) for credential access Enable Azure Policy to enforce certificate-based authentication Domain limitations if applicable 🛡️ Container-level security features Q: What security controls are available at the container level? A: SharePoint Embedded provides granular security controls for each container: Sensitivity labels: Enforce encryption and access policies Automatically applied to all content in container Integrated with Microsoft Purview Information Protection Block download policy: View-only access for high-sensitivity content Prevents data exfiltration Supports watermarking in Office web apps Container permissions: Four permission levels available: Owners: Full control including container deletion Managers: Manage content and permissions (cannot delete container) Writers: Add, update, and delete content Readers: View-only access Q: How does SharePoint Embedded handle external user collaboration? A: SharePoint Embedded supports secure external collaboration through multiple mechanisms: Authentication options: Entra ID guest users: External users invited as B2B guests Email-based sharing: Send secure access links with expiration Anonymous links: View-only or edit links without authentication (configurable) Security controls: Container-level sharing policies may supersede tenant default settings; however, they do not impact other configurations within the tenant. Link expiration dates and access revocation Audit trail for all external user activities Integration with Data Loss Prevention (DLP) policies Sharing configuration best practices: Enable guest sharing only for required applications Require email verification for sensitive content Monitor external access through Microsoft Purview audit logs Real-world scenarios: Legal firms: Share case documents with external counsel using time-limited guest access Construction projects: Collaborate with subcontractors while maintaining security boundaries Financial services: Enable secure document exchange with clients using DLP policies 📋 Compliance & data governance Q: What Microsoft Purview features are supported? A: SharePoint Embedded integrates with the full Microsoft Purview compliance suite: Audit logging: All user and admin operations captured in unified audit log Enhanced with ContainerTypeId for filtering Search and export capabilities through Microsoft Purview Retention up to 10 years (with E5 license) eDiscovery: Search across all SharePoint Embedded containers Place legal holds on container content Review content to determine if it should be tagged and included in the case Export content for litigation or investigation Data lifecycle management (DLM): Apply retention policies to containers Automatic deletion after retention period Hold policies for litigation or investigation Label-based retention rules Implementation: Retention policies apply to "All Sites" automatically to include SPE containers Selective enforcement using container URLs Graph API for programmatic label application Data loss prevention (DLP): Identify and protect sensitive information Prevent external sharing of classified content Policy tips and user notifications Automatic encryption and access restrictions DLP policy enforcement: Real-time scanning of uploaded content Block external sharing based on content type Business justification workflows (app-dependent) Integration with sensitivity labels Q: How are DLP policies enforced in SharePoint Embedded? A: DLP works similarly to SharePoint Online with some considerations: Supported scenarios: Automatic detection of sensitive information (PII, financial data, etc.) Policy enforcement on upload, download, and sharing Alert generation for policy violations Integration with Microsoft Purview compliance center Application responsibilities: Since SharePoint Embedded has no built-in UI, applications must: Display policy tips to users when DLP flags content Handle business justification workflows for policy overrides Implement sharing restrictions when DLP blocks external access Use Graph APIs to retrieve DLP policy status Best practice: Test DLP policies on pilot containers before organization-wide deployment. 🔒 Advanced security scenarios Q: How do we implement least-privilege access for SharePoint Embedded? A: Follow these principles for robust security architecture: Q: What are common security misconfigurations to avoid? A: Learn from real customer experiences: ❌ Common Mistake 1: Assigning application permissions to user activities Problem: No audit trail, all actions appear as "application" Solution: Use delegated permissions for interactive scenarios ❌ Common Mistake 2: Storing secrets in application code Problem: Credential exposure in version control Solution: Use Azure Key Vault with managed identities ❌ Common Mistake 3: Ignoring conditional access configuration Problem: Service principals accessible from any network Solution: Configure named locations and conditional access policies ❌ Common Mistake 4: Not testing admin consent flow Problem: Consuming tenant onboarding failures Solution: Use admin consent URL method: https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent?client_id={client-id}&redirect_uri={redirect-uri} 🏢 Enterprise security best practices Q: What security hardening steps should we implement? A: Follow this layered security approach: Level 1: Basic hardening Access controls: [ ] Implement least privilege principles [ ] Use delegated permissions for user-facing operations [ ] Regular permission audits (quarterly) [ ] Remove unused API permissions Authentication: [ ] Enable certificate-based authentication [ ] Configure MFA for all admin accounts [ ] Implement password-less authentication where possible [ ] Use managed identities for Azure-hosted apps Network security: [ ] Configure Conditional Access policies [ ] Define trusted IP ranges (Named Locations) [ ] Block legacy authentication protocols [ ] Enable sign-in risk policies Level 2: Advanced hardening Monitoring & alerting: [ ] Enable Microsoft Defender for Cloud Apps [ ] Configure alerts for suspicious activities: Unusual download volumes Access from unexpected locations Permission changes Guest user additions [ ] Integrate audit logs with SIEM (Sentinel, Splunk) [ ] Establish baseline for normal activity Compliance: [ ] Apply sensitivity labels to containers [ ] Implement DLP policies for sensitive data [ ] Configure retention policies [ ] Regular compliance assessments Incident response: [ ] Document container emergency access procedures [ ] Define escalation paths for security incidents [ ] Test access revocation processes [ ] Maintain audit log retention for forensics Level 3: Zero trust architecture Continuous verification: [ ] Device compliance requirements [ ] Session-based access controls [ ] Real-time risk assessment [ ] Automated response to anomalies 📚 Additional resources Official documentation Security and Compliance Overview Container Permissions API Microsoft Purview DLP Conditional Access Policies Security best practices SharePoint Embedded Admin Guide Entra ID Application Security Zero Trust Security Model Have more questions or want to talk to the team, contact us: SharePointEmbedded@microsoft.comMicrosoft Ignite- Meaningful Announcements That Create Real Movement
Now that we are officially in 2026, I want to reflect back on Microsoft Ignite as it was more energized than ever. There is real momentum right now across Microsoft Marketplace, and the most meaningful shift I am seeing is around REO( Reseller Enabled Offer )capability. This is opening the door for partners to take Marketplace offers and bring them directly into new regions, new customer segments, and new routes to market without adding operational friction for either side. A true channel selling motion! For ISVs, REO means you can authorize trusted partners to resell your Marketplace offer in the way that works best for the customer. You no longer need to manage every deal yourself. For partners, it means instant access to in demand AI and security solutions that customers are already asking for. It removes barriers, it speeds up the process, and it connects the ecosystem in a much more natural way. If anyone in the community is exploring REO, private offers, multiparty models, or Marketplace strategy in general, it would be great to hear from you or reach out and would love to discuss. Looking forward to connecting with everyone in the new year. justinroyal
'Unknown Error' while completing Microsoft ISV Success Sign Up
While completing my ISV Success signup, after pressing 'Agree and Continue' and verifying all input fields, it shows me "An unknown error occurred, please try again later". Why is it showing this error? All the fields have been filled correctly. Can someone assist me with this? Has anyone else faced and resolved this error? I have attached the screenshot of the error as well. Thanks.
