Security Overview

This document provides full security documentation for the App Store for Intune, including all Azure resources created, permissions granted, and security configurations. It is intended to assist security teams with reviews and compliance requirements.

Table of contents

1. Azure resources created
2. Identity and access management
3. Microsoft Entra ID app registration
4. Managed identity configuration
5. Network security
6. Data protection
7. Authentication flow
8. Authorization model
9. Audit logging
10. Security checklist
11. Package verification

---

Azure resources created

The ARM template deploys the following resources:

Resource Type	Name Pattern	Purpose
App Service Plan	asp-apprequest-{env}	Hosts the web application
App Service	apprequest-{env}-{unique}	ASP.NET Core API + React SPA
Azure Key Vault	kv-appreq-{unique}	Secure secret storage
SQL Server	sql-apprequest-{env}-{unique}	Database server
SQL Database	AppRequestPortal	Application data storage
Storage Account	stappreq{unique}	Queue + blob storage for packaging
Application Insights	ai-apprequest-{env}	Application monitoring
Log Analytics Workspace	la-apprequest-{env}	Centralized logging
Azure Bot	bot-apprequest-{env}-{unique}	Teams proactive messaging (optional)
Bot Teams Channel	{bot}/MsTeamsChannel	Enables Teams communication (optional)

Resource configuration details

App Service

• Runtime: .NET 8.0 on Linux
• TLS Version: Minimum TLS 1.2 enforced
• HTTPS Only: Enabled (HTTP redirects to HTTPS)
• FTPS State: Disabled (no FTP access)
• Client Affinity: Disabled (stateless application)
• Always On: Enabled (prevents cold starts)

SQL Server

• TLS Version: Minimum TLS 1.2
• Firewall: Only Azure services allowed (0.0.0.0-0.0.0.0)
• Authentication: SQL authentication (username/password)

Azure Bot (optional)

• SKU: F0 (Free)
• Location: Global
• App Type: UserAssignedMSI
• Microsoft App ID: the client ID of the bot’s own user-assigned managed identity (Bot:UamiClientId), created by the deploy template when the Teams bot is enabled
• Messaging Endpoint: https://{app-url}/api/messages
• Channels: Microsoft Teams only
• Authentication: Bot Framework handles its own authentication via ConfigurationBotFrameworkAuthentication, using that managed identity

Bot Framework Authentication Model:

• As of v1.30.0 the Azure Bot resource uses a dedicated user-assigned managed identity. It does not use the portal app registration, and there is no client secret in this path.
• That identity holds no Microsoft Graph or Intune permissions. It authenticates to Bot Framework and nothing else. Expanding the group behind a notification is done by the App Service’s system-assigned managed identity, like every other Graph call.
• Proactive messages are sent via BotAdapter.ContinueConversationAsync or CreateConversationAsync, authenticated with the same managed identity
• No additional Microsoft Graph API permissions are required for Teams bot notifications. Bot Framework handles its own auth channel.

Data stored:

• BotConversationReferences table stores per-user conversation references for proactive messaging
• Contains: User ID (Microsoft Entra ID object ID), Conversation ID, Service URL, serialized ConversationReference JSON
• Conversation references are encrypted/signed by Bot Framework and tied to the bot credentials that created them
• If bot credentials change, existing conversation references become invalid and must be cleared

---

Identity and access management

System-assigned managed identity

The App Service is configured with a System-Assigned Managed Identity. This identity is automatically created and managed by Azure.

"identity": {
  "type": "SystemAssigned"
}

Purpose: The Managed Identity allows the application to authenticate to Azure services without storing credentials in code or configuration.

Role assignments

The following permissions are granted to the Managed Identity:

Permission Type	Scope	Purpose
Website Contributor Role	App Service	Enables in-app updates via Azure Resource Manager
Key Vault Access Policy (Get, List Secrets)	Key Vault	Read application secrets from Key Vault

Why Website Contributor?

The in-app update feature allows administrators to update the application from within the portal. To do this, the application must be able to modify its own WEBSITE_RUN_FROM_PACKAGE app setting. The Website Contributor role grants this permission.

Why Key Vault Access?

Sensitive connection strings (SQL, storage) are stored in Azure Key Vault and read at runtime through the App Service’s managed identity.

There is no Microsoft Entra ID client secret. The App Service authenticates to Microsoft Graph as its own system-assigned managed identity and the Teams bot as its own user-assigned managed identity, so there is no application password anywhere in the product to store, reference, rotate or lose.

Scope limitation: All permissions are scoped to the minimum required resources (not the resource group or subscription), following the principle of least privilege.

{
  "type": "Microsoft.Authorization/roleAssignments",
  "scope": "[concat('Microsoft.Web/sites/', variables('appName'))]",
  "properties": {
    "roleDefinitionId": "[subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'de139f84-1756-47ae-9be6-808fbbe84772')]",
    "principalId": "[reference(resourceId('Microsoft.Web/sites', variables('appName')), '2022-09-01', 'full').identity.principalId]",
    "principalType": "ServicePrincipal"
  }
}

---

Microsoft Entra ID app registration

App Store for Intune uses a single Microsoft Entra ID app registration. It serves two roles bound to the same client ID: it validates incoming user tokens (the API trusts only tokens whose audience matches this client ID, then checks the scope) and it powers the single-page application sign-in flow.

Application type: Single-page application (SPA)

Authentication:

• Client ID only. There is no client secret: the App Service uses its managed identity for all service-to-service calls.
• MSAL.js with the authorization code flow and PKCE

API permissions (delegated):

API	Permission	Type	Purpose
Microsoft Graph	User.Read	Delegated	Read the signed-in user’s profile and photo

Token configuration:

• Access tokens issued for: api://{client-id}
• Scope exposed: access_as_user

Redirect URIs (Single-page application platform):

• https://{app-name}.azurewebsites.net/
• https://{custom-domain}/ (if a custom domain is configured)

The Microsoft Graph application permissions App Store uses to call Intune, manage groups, read users, and send mail are not held on this app registration. They are granted to the App Service’s managed identity instead. See Managed identity configuration.

Optional: the workload API registration

If you enable unattended API access, a second app registration exists, separate from the sign-in one above. It holds no client secret, no certificate, no Microsoft Graph permissions and no Intune permissions. Its only contents are an Application ID URI, which names the audience, and App Store’s application roles.

Keeping it separate is deliberate: the registration your staff authenticate against keeps its property of holding no credentials and no application roles, and a mistaken role assignment on a registration that exists only to hold roles cannot reach the sign-in identity.

The caller authorised through it is a customer-controlled managed identity, typically an Azure Automation Account’s. It can perform seven reads and cannot approve, reject or change anything. See Call the API from Azure Automation.

If unattended access is not configured, this registration does not exist and App Store accepts no application token.

Teams bot note: No Microsoft Graph permissions are required for Teams bot notifications. Bot Framework handles its own authentication, and as of v1.30.0 the bot authenticates with a dedicated user-assigned managed identity (no client secret). Do not add TeamsActivity.Send or similar permissions; they are not used by this application.

---

Managed identity configuration

How the managed identity works

1. Creation: When the ARM template deploys, Azure automatically creates a service principal in Microsoft Entra ID for the App Service.

2. Environment variables: Azure injects these environment variables into the application:

   • MSI_ENDPOINT or IDENTITY_ENDPOINT: Token endpoint URL
   • IDENTITY_HEADER: Secret header for authentication
   • WEBSITE_SITE_NAME: App Service name
   • WEBSITE_RESOURCE_GROUP: Resource group name
   • WEBSITE_OWNER_NAME: Subscription ID

3. Token acquisition: The application uses DefaultAzureCredential from Azure.Identity SDK to acquire tokens:

   var credential = new DefaultAzureCredential();
   var armClient = new ArmClient(credential);

4. Authorization: The Managed Identity authenticates to Azure Resource Manager and is authorized via the Website Contributor role assignment.

Microsoft Graph application permissions

The same system-assigned managed identity also holds the Microsoft Graph application permissions App Store uses to call Microsoft Graph as itself, with no client secret. These are granted once after deployment by the Grant Microsoft Graph permissions PowerShell snippet:

Permission	Purpose
DeviceManagementApps.Read.All	Read the Intune app catalog and assignment state
DeviceManagementApps.ReadWrite.All	Create and update Intune Win32 app deployments
DeviceManagementConfiguration.Read.All	Read Intune assignment filters used by ring deployment settings
DeviceManagementManagedDevices.Read.All	Read managed devices associated with the requesting user
Device.Read.All	Resolve an Entra device from its Azure AD Device ID. Group membership is added by directory object, so this is what lets an app assigned to devices reach the device
Group.ReadWrite.All	Create and manage the security groups that drive app assignments
GroupMember.Read.All	Resolve whether a user is in a group, which is how the admin, approver, portal access and app target groups are evaluated
User.Read.All	Read user profiles, managers, and group memberships for approvals
Mail.Send	Send email notifications from a configured mailbox (optional)
DeviceManagementManagedDevices.PrivilegedOperations.All	Ask a device to check in with Intune, for the Check status action on My Devices (optional, not granted by default)

App Store asks for the narrowest permission that does each job. Device.Read.All grants reading device objects and nothing more; Directory.Read.All, which would also cover it, is deliberately not requested.

The one optional permission is the exception, and not by choice. DeviceManagementManagedDevices.PrivilegedOperations.All is the only permission Microsoft offers for a device check-in, and the same grant also covers wipe, retire, and rename. There is no narrower tier. App Store never calls wipe, retire, or rename; it calls check-in and nothing else. Because the granted authority is wider than the feature, the permission is left out of the setup snippet, has to be granted deliberately, and then still does nothing until an administrator separately enables the action in Store Administration. Every attempt is written to the audit log, refusals included.

What the managed identity can do

• Call Microsoft Graph as the application using the granted permissions above (read and write Intune apps, manage groups, read users, send mail)
• Read and update the App Service’s own configuration settings
• Read the App Service’s properties
• Restart the App Service
• Read secrets from the provisioned Key Vault (Get, List permissions only)

What the managed identity can’t do

• Access other resources in the subscription
• Modify other App Services
• Write, delete, or manage secrets in Key Vault
• Access SQL Database directly (uses SQL authentication via connection string from Key Vault)
• Deploy or delete resources

---

Network security

Inbound traffic

Protocol	Port	Source	Destination	Purpose
HTTPS	443	Internet	App Service	User access
HTTPS	443	App Service	Azure SQL	Database connections
HTTPS	443	App Service	Microsoft Graph	API calls
HTTPS	443	Bot Framework Service	App Service	Teams bot messages (/api/messages)
HTTPS	443	App Service	Bot Framework Service	Proactive bot notifications

App Service network configuration

• Public Access: Enabled (internet-accessible)
• TLS 1.2: Minimum version enforced
• HTTPS Only: HTTP requests redirected to HTTPS
• IP Restrictions: None by default (can be configured)

SQL Server firewall

The SQL Server is configured with the following security controls:

• Azure Services: Allowed (firewall rule AllowAllWindowsAzureIps)
  • This allows the App Service to connect to the database
  • Other Azure services in the subscription cannot access unless explicitly allowed
• Public IP Access: Denied by default
  • No client IP addresses are on the allowlist
  • Database is not accessible from the internet
• Private Endpoint: Not configured by default (can be added for enhanced security)

Caution

The database is not accessible from the public internet. Only Azure services (such as the App Service) can connect.

To verify SQL firewall rules:

az sql server firewall-rule list --server <server-name> --resource-group <rg-name>

To add a client IP for temporary admin access:

az sql server firewall-rule create --server <server-name> --resource-group <rg-name> \
  --name "AdminAccess" --start-ip-address <your-ip> --end-ip-address <your-ip>

Remember to remove temporary rules after use.

Recommendations for enhanced security

Conditional Access policies

We strongly recommend configuring the following Microsoft Entra ID Conditional Access policies for App Store for Intune. Target them at the App Store app registration. Since v1.34.0 there is one registration: it both hosts the single-page application sign-in and is the audience the API validates tokens against, so a single policy covers the whole sign-in path.

Policy	Description	Why It Matters
Require MFA	Require multifactor authentication for all users accessing the portal	Prevents unauthorized access from compromised credentials
Require compliant device	Only allow access from Intune-compliant devices	Since this portal manages Intune apps, ensuring the requesting device meets compliance is a natural fit
Require managed device	Only allow access from Microsoft Entra ID joined or hybrid joined devices	Prevents access from personal/unmanaged devices
Block risky sign-ins	Block sign-ins flagged as medium or high risk by Microsoft Entra ID Identity Protection	Automatically blocks access when suspicious activity is detected (requires Microsoft Entra ID P2)
Restrict by location	Only allow access from trusted named locations (office IPs, VPN ranges)	Limits exposure to known network boundaries
Sign-in frequency	Require re-authentication every 8-12 hours	Limits the window of exposure from a stolen session token

Recommended minimum

At a minimum, enable Require MFA and Require compliant device. These two policies provide strong protection without significant user friction, especially for organizations already using Intune for device management.

Admin vs User policies

Consider creating a stricter policy for the Admin Group (e.g., require phishing-resistant MFA, restrict to trusted locations) since admins can modify portal settings, manage apps, and approve requests.

Network security enhancements

1. Virtual network integration: Deploy App Service into a VNet
2. Private endpoints: Use private endpoints for SQL and storage
3. IP restrictions: Limit access to known IP ranges
4. Azure Front Door: Add WAF protection

---

Data protection

Data at rest

Data Type	Storage Location	Encryption
Application data	Azure SQL Database	TDE (Transparent Data Encryption)
User settings	Azure SQL Database	TDE
Branding assets	Azure SQL Database	TDE
Bot conversation references	Azure SQL Database	TDE
Logs	Log Analytics	Azure-managed encryption

Data in transit

• All communication uses TLS 1.2+
• HTTPS enforced at App Service level
• SQL connections use encrypted connections

Sensitive data handling

Data	Storage Method	Notes
SQL Connection String	Azure Key Vault	Referenced via Key Vault reference in App Settings
Storage Connection String	Azure Key Vault	Referenced via Key Vault reference in App Settings
User tokens	Session storage (browser)	Not persisted server-side
Action tokens	SQL Database	GUID per request, used for email approve/reject
Bot conversation references	SQL Database	Conversation IDs and service URLs for Teams proactive messaging
Audit logs	SQL Database	Retained indefinitely

Secrets management

All sensitive secrets are stored in Azure Key Vault and accessed via Key Vault references:

ConnectionStrings__DefaultConnection = @Microsoft.KeyVault(SecretUri=https://{vault}.vault.azure.net/secrets/SqlConnectionString/)
AzureStorage__ConnectionString = @Microsoft.KeyVault(SecretUri=https://{vault}.vault.azure.net/secrets/StorageConnectionString/)

Key Vault security features:

• Secrets encrypted at rest with Azure-managed keys
• Soft delete enabled (7-day retention for accidental deletion recovery)
• Access restricted to the App Service’s Managed Identity only
• No direct secret access for users or administrators (must use Azure Portal/CLI with appropriate permissions)
• All secret access is logged in Key Vault diagnostic logs

Secret and key rotation

Microsoft Entra ID credentials:

App Store no longer uses a client secret. The App Service authenticates to Microsoft Graph with its managed identity, so there is no Microsoft Entra ID secret to rotate or expire.

SQL password rotation:

1. Reset password in Azure Portal → SQL Server → Reset admin password
2. Update connection string in Key Vault:

   az keyvault secret set --vault-name <vault-name> --name SqlConnectionString --value "Server=tcp:..."

3. Restart App Service

Emergency key rotation:

If you suspect a secret has been compromised:

1. Immediately rotate the affected secret using the steps above
2. Review Key Vault access logs for unauthorized access
3. Review App Service logs for unusual activity
4. Consider rotating all secrets if compromise scope is unknown

Certificate management

SSL certificates:

Certificate Type	Management	Renewal
Azure-managed (default)	Automatic	Auto-renewed by Azure
Custom domain with Azure certificate	Automatic	Auto-renewed by Azure
Custom uploaded certificate	Manual	Upload new certificate before expiration

Microsoft Entra ID app credentials:

There are none to monitor. The App Store app registration has no client secret and no certificate; both identities that do privileged work are managed identities, and Azure issues those tokens to the workload itself.

Monitoring expiration:

Set up Azure Monitor alerts for:

• Key Vault secret expiration (90 days before), for the SQL and storage connection strings
• SSL certificate expiration (if you use a custom domain)

# Check Key Vault secret expiration dates
az keyvault secret list --vault-name <vault-name> --query "[].{name:name, expires:attributes.expires}"

---

Authentication flow

┌──────────────┐         ┌──────────────┐         ┌──────────────┐
│   Browser    │         │   Entra ID   │         │  App Service │
└──────┬───────┘         └──────┬───────┘         └──────┬───────┘
       │                        │                        │
       │  1. Navigate to app    │                        │
       │───────────────────────────────────────────────>│
       │                        │                        │
       │  2. Redirect to sign-in│                        │
       │<───────────────────────────────────────────────│
       │                        │                        │
       │  3. User authenticates │                        │
       │───────────────────────>│                        │
       │                        │                        │
       │  4. Return tokens      │                        │
       │<───────────────────────│                        │
       │                        │                        │
       │  5. API call with token                         │
       │───────────────────────────────────────────────>│
       │                        │                        │
       │                        │  6. Validate token     │
       │                        │<───────────────────────│
       │                        │                        │
       │                        │  7. Token valid        │
       │                        │───────────────────────>│
       │                        │                        │
       │  8. API response       │                        │
       │<───────────────────────────────────────────────│

Token validation

The API validates JWT tokens from Microsoft Entra ID:

1. Issuer: Must match Microsoft Entra ID tenant
2. Audience: Must match API Client ID
3. Signature: Validated using Microsoft Entra ID public keys
4. Expiration: Token must not be expired
5. Claims: User identity extracted from token

---

Authorization model

Role-based access control

Role	How Assigned	Capabilities
User	Any authenticated user	Browse apps, submit requests, view own requests
Approver	Member of Approver Microsoft Entra ID Group	Approve/reject requests, view pending approvals
Admin	Member of Admin Microsoft Entra ID Group	Full access, manage apps, settings, users

Group-based authorization

Authorization groups are configured in the database (PortalSettings table):

AdminGroupId      -- Microsoft Entra ID Group Object ID for admins
ApproverGroupId   -- Microsoft Entra ID Group Object ID for approvers
UserAccessGroupId -- (Optional) Restrict access to specific group

Authorization check flow

// Check if user is admin
var userId = User.FindFirstValue("oid");
var isAdmin = await _azureADService.IsUserInGroupAsync(userId, adminGroupId);

---

Audit logging

What is logged

Event	Data Captured
App request submitted	User ID, App ID, Device ID, Timestamp
Request approved/rejected	Reviewer ID, Decision, Comments, Timestamp
Settings changed	User ID, Setting changed, Old/New values
App sync	User ID, Apps added/updated, Timestamp
User sign-in	User ID, IP address, Timestamp
Administrative change (1.39.0)	Every write action in the administration API (settings, apps, workflows, packaging, updates, permissions) is recorded as Controller.Action with User ID, IP address, Timestamp
Access denied (1.39.0)	Access.Denied: the endpoint and the identity that was refused
Request cancelled (1.39.0)	Request.Cancelled: User ID, Request ID, Timestamp
Portal update (1.39.0)	Portal.UpdateRequested and Portal.UpdateInstalled, including the package URL applied and the one it replaced

Audit log storage

• Location: SQL Database (AuditLogs table)
• Retention: Indefinite (no automatic purge)
• Access: Admin-only via Reports section

Log schema

CREATE TABLE AuditLogs (
    Id NVARCHAR(450) PRIMARY KEY,
    UserId NVARCHAR(450) NOT NULL,
    UserEmail NVARCHAR(255) NOT NULL,
    Action NVARCHAR(100) NOT NULL,
    EntityType NVARCHAR(100) NOT NULL,
    EntityId NVARCHAR(450) NOT NULL,
    Details NVARCHAR(MAX),  -- JSON payload
    Timestamp DATETIME2 NOT NULL,
    IpAddress NVARCHAR(50) NOT NULL
);

---

Security checklist

Pre-deployment

• App Store app registration created with delegated User.Read only, no client secret, and no application permissions
• Microsoft Graph application permissions granted to the App Service’s managed identity, not to the app registration
• Admin consent granted for application permissions
• Strong SQL administrator password configured
• Deployed by a person, who becomes the initial administrator, or, for an automated deployment, Admin Group ID configured
• Approver Group ID configured (restricts approver access)

Post-deployment

• Verify HTTPS-only access working
• Test authentication flow
• Verify role-based access (admin vs. user)
• Review Microsoft Entra ID sign-in logs
• Enable Azure Security Center recommendations
• If Teams bot enabled: verify Azure Bot App ID matches AzureAd:ClientId
• If Teams bot enabled: test bot notification delivery

Ongoing operations

• Review audit logs regularly
• Monitor failed authentication attempts
• Update application when security patches released
• Review and remove unused app permissions

Optional enhancements

• Enable Microsoft Entra ID Conditional Access policies (see Recommended Policies)
• Configure Microsoft Entra ID Identity Protection (required for risk-based CA policies)
• Implement Private Endpoints for SQL and Key Vault
• Add Azure Front Door with WAF
• Enable Azure Defender for App Service
• Azure Key Vault for secrets (enabled by default)

---

Package verification

Apps deployed to Intune via the App Store originate as YAML manifests in the microsoft/winget-pkgs community repository. Each manifest declares an installer URL and the SHA256 hash that installer must match. The packaging pipeline verifies the downloaded installer against that hash before wrapping it for Intune (PackagingQueueService.DownloadFromGitHubAsync).

That hash check defends against a tampered installer at the publisher’s download server, but it trusts the manifest itself. The manifest is fetched from raw.githubusercontent.com over HTTPS, and anyone able to MITM that connection (or substitute a manifest in a compromised mirror) could feed the pipeline a manifest that points at a malicious installer with a matching hash.

Verified chain via source2.msix

To close that gap, the App Store can verify each package against Microsoft’s signed community index. The WinGet client itself uses this same chain (see PackagesTable.h in winget-cli for the upstream schema).

How it works (when VerifyManifestIntegrity is enabled):

1. The portal downloads source2.msix from https://cdn.winget.microsoft.com/cache/source2.msix.
2. The .msix contains a SQLite database (Public/index.db) with a packages table: one row per package Microsoft has reviewed and merged into the community repository, with the SHA256 of the package’s version data manifest in the hash column.
3. Before packaging any WinGet-sourced app, the portal looks the package up in this index. If the package is not present, the packaging job fails with an explicit “Manifest integrity check failed” error rather than silently falling back to an unverified path.
4. The downloaded MSIX and extracted SQLite are cached on disk for 12 hours so repeat lookups don’t re-download the ~10 MB archive.

What this protects against:

• Tampered manifest substituted on the GitHub fetch path. A malicious manifest for a non-existent or non-merged package ID will fail the index lookup.
• An attacker pointing an existing package ID at a different installer. Once paired with the version-data-manifest hash check (planned, see roadmap below), the manifest contents can be cryptographically tied back to what Microsoft moderators reviewed.

What this does not yet protect against (v1 limitations):

• The full design (documented internally as the WinGet manifest verification specification) calls for fetching the version data manifest from the Azure CDN by content-addressed URL and verifying its hash against the SQLite value, then doing the same for each per-version merged manifest. v1 implements only the index lookup gate; the hash-of-manifest comparison is a planned v2 enhancement.
• MSIX signature validation against Microsoft’s certificate chain (Authenticode-on-MSIX via WinTrust). v1 relies on HTTPS + DNS to cdn.winget.microsoft.com as the trust root. A compromised CDN is out of scope for v1; v2 will add full signature validation.

Configuration: Store Administration > System, Catalog Sourcing, “Verify manifest integrity against Microsoft’s signed index”. Default is on. An upgrade turns it on once for installations that predate the default; after that an administrator’s choice is kept. Admins running internal hardened mirrors of the WinGet repo can turn it off and rely on their mirror’s own integrity controls.

What the check does, precisely. It confirms that the package ID is present in Microsoft’s signed index and refuses to package anything that is not. It does not compare the contents of the manifest fetched from GitHub with the index. Separately, the installer the portal downloads must match the SHA-256 published in the manifest for the version being packaged, or packaging stops.

Failure mode: Verification failures are loud, not silent. The packaging job is marked failed and the error message names the package and explains the integrity check failed. There is no fallback to the unverified path while verification is enabled. The only escape valve is to disable the setting from the Settings page.

---

Compliance considerations

Data residency

• All data stored in the Azure region selected during deployment
• No cross-region data replication by default

Data retention

• Audit logs: Retained indefinitely
• Application data: Retained until manually deleted
• App Insights logs: 90 days default (configurable)

GDPR considerations

• User data limited to: Name, Email, User ID (from Microsoft Entra ID)
• No sensitive personal data stored
• Data can be exported/deleted upon request via database access

---

Incident response

Security event indicators

Monitor for these events in Microsoft Entra ID and App Insights:

1. Multiple failed sign-ins from same IP
2. Unusual geographic access patterns
3. Bulk data access (many API calls in short time)
4. Privilege escalation attempts
5. Configuration changes outside business hours

Response actions

1. Disable App Service if compromise suspected
2. Rotate secrets (SQL password, storage keys). There is no Entra ID client secret to rotate; the App Service and the Teams bot both use managed identities
3. Review audit logs for unauthorized access
4. Revoke user access if account compromised
5. Contact Azure Support for assistance

---

Contact

For security questions or to report vulnerabilities:

• Email: info@powerstacks.com