Skip to content

Brief Connect v2.6.x Infrastructure Release Notes

Release date - 29th June, 2026

Supported package versions: 2.6.x

This release is an infrastructure security hardening release for environments already running Brief Connect package 2.6.x. It also addresses Microsoft's Azure Cache for Redis retirement by moving guidance and deployment patterns to Azure Managed Redis. There is no Brief Connect application package upgrade in this release.

Who should use this guide

Use this page if you manage Brief Connect infrastructure and deployment pipelines.

What changed

Security hardening direction (Entra ID-first)

  • Runtime access patterns are hardened toward Microsoft Entra ID-first and managed identity-based authentication.
  • Shared key and secret-based connectivity is reduced for supported Azure Storage, MongoDB, and Redis paths.
  • RBAC coverage is expanded for deployment and runtime identities to support keyless access patterns.

Azure Cache for Redis retirement response

Infrastructure security model implementation updates

  • Guidance for Azure DocumentDB (MongoDB), Azure Managed Redis, and Azure Storage accounts now aligns to a Microsoft Entra ID-first model and managed identity usage.
  • Azure Storage account guidance now prioritizes endpoint-based settings where keyless authentication is supported.
  • Deployment guidance includes updated Role-Based Access Control (RBAC) expectations for the deployment identity.

Infrastructure settings documentation updates

  • Managed identity settings are clarified for Azure DocumentDB (MongoDB), Azure Managed Redis, and Azure Storage accounts.
  • Endpoint-based Azure Storage account settings are documented for Entra ID authentication scenarios.
  • Plugins storage guidance is updated for environments that use Plugins Editor with Entra ID authentication.
  • Related settings reference: Infrastructure Settings.

Solution and deployment documentation alignment

Infrastructure upgrade actions

Non-standard infrastructure

The steps below apply to standard Brief Connect base infrastructure and release pipelines. If your environment uses hardened or custom infrastructure (for example VNets, private endpoints, custom RBAC models, or alternative Infrastructure as Code tools), align the upgrade plan with the E2 support team before deployment.

Complete these steps for each target environment.

What will be changed

Short summary

  • Runtime connectivity shifts to managed identity patterns across MongoDB, Redis, and Azure Storage accounts.
  • Azure DocumentDB (MongoDB) supports Microsoft Entra ID authentication and provisions Entra-backed users for API and Function runtimes.
  • Redis moves to Azure Managed Redis (redisEnterprise resources), with key-based authentication disabled and Function identity-based database policy assignment.
  • Azure Storage account access is hardened by disabling shared key access and using endpoint-plus-RBAC settings.
  • Deployment automation consumes web storage output and applies post-deployment blob data access for the DevOps app.

New RBAC roles introduced in this change set

  • Storage Blob Data Owner (b7e6dc6d-f1e8-4753-8033-0f276bb0955b)
  • Storage Table Data Contributor (0a9a7e1f-b9d0-4cc4-a60d-0319b160aaa3)
  • Storage Queue Data Contributor (974c5e8b-45b9-4653-ba55-5f855dd0fb88)

Storage Account Contributor and Key Vault Secrets User remain in use from earlier releases.

Resource-scoped change details

  • Azure DocumentDB (MongoDB vCore)
    • Bicep module name changes from mongoVCore.bicep to mongoAzDocumentDb.bicep.
    • Cluster authentication allows both NativeAuth and MicrosoftEntraID.
    • Entra-backed Mongo users are provisioned for both app runtimes (Function App and API Web App).
    • Mongo connection output and Key Vault secret population now use the Entra connection output.
    • Region input is clarified with mongoAzDocumentDbRegion.
  • Azure Managed Redis
    • Deployment model changes from Microsoft.Cache/Redis to module-based Microsoft.Cache/redisEnterprise + database resources.
    • Database key authentication is disabled (accessKeysAuthentication: Disabled).
    • Function App identity receives Redis database access policy assignment (default).
    • Redis connection output uses host/port pattern without secret key material.
    • SKU input changes from object (redisCacheSku) to name string (redisCacheSkuName), with defaults Balanced_B0 (non-prod) and Balanced_B1 (prod).
  • Function App (Microsoft.Web/sites)
    • Resource ordering is adjusted to support downstream identity-dependent resources.
    • Function principal ID is consumed by Redis policy assignment, Mongo Entra user provisioning, and Azure Storage RBAC assignments.
    • App settings move to managed-identity-friendly Mongo/Redis/Azure Storage configuration.
  • API Web App (Microsoft.Web/sites)
    • API principal ID is passed to Mongo provisioning for Entra-backed Mongo user creation.
    • App settings align to managed identity-based data access.
  • Azure Storage account (Web)
    • allowSharedKeyAccess is disabled.
    • Blob endpoint output is used for plugin bundle settings when enabled.
    • Conditional Blob Data Owner assignment is added for Function App identity when plugin bundles use web blob storage.
    • azureStorageAccountWebResourceId output is added for downstream automation.
  • Azure Storage account (Function)
    • allowSharedKeyAccess is disabled.
    • Function runtime storage access moves from connection-string secret usage to endpoint-based app settings:
      • AzureWebJobsStorage__blobServiceUri
      • AzureWebJobsStorage__queueServiceUri
      • AzureWebJobsStorage__tableServiceUri
    • Function App identity gains Azure Storage RBAC for blob, table, queue, and account-contributor operations.
  • Azure Storage account (Data)
    • allowSharedKeyAccess is disabled.
    • Key-based connection string patterns are removed from template flow.
    • Function App identity gains Storage Account Contributor and Storage Queue Data Contributor.
    • Data storage app settings move to endpoint-based configuration:
      • DataStorageAccountConnectionString__queueServiceUri
      • DataStorageUseManagedIdentity=true
  • Key Vault
    • Storage connection string secrets are no longer created for Function/Data storage accounts.
    • Mongo connection secret now uses the Entra-based connection output.
    • Redis secret remains but is sourced from Azure Managed Redis module output.
  • Application configuration surface (API + Function)
    • Temporary Mongo setting names are replaced with canonical names:
      • TempMongoDbConnectionString -> MongoDbConnectionString
      • TempMongoDbPassword -> MongoDbPassword
    • Managed identity intent flags are introduced:
      • MongoDbUseManagedIdentity
      • RedisUseManagedIdentity
      • DataStorageUseManagedIdentity
    • Plugin storage behavior is configurable through isWebStorageBlobUsedForPlugins.
  • Deployment outputs and automation
    • Bicep/main-2.bicep adds azureStorageAccountWebResourceId and removes deprecated outputs (azureDocumentDbResourceId, azureSqlDatabaseId, azureSqlServerFqdn).
    • Scripts/ProvisionInfra.ps1 requires MainMongoDbType, reads devOpsAppRegistrationClientId, and performs idempotent Blob Data Owner assignment for the DevOps app on web storage scope.

1) Update deployment identity RBAC assignment conditions

Update the Role Based Access Control Administrator assignment conditions for [EnvPrefix] Brief Connect DevOps to include:

  • Storage Account Contributor
  • Storage Blob Data Owner
  • Storage Table Data Contributor
  • Storage Queue Data Contributor
  • Key Vault Secrets User
  • Key Vault Secrets Officer

Related deployment guide sections:

2) Update environment parameter generation and variable groups

Update /Scripts/Environments/Generate[EnvName]Params.ps1 and the environment variable group so they match the current infrastructure templates.

  • Confirm your variable group includes current values for shared deployment parameters.
  • If using Atlas topology, confirm AtlasOrganizationId, AtlasDevOpsAppId, and AtlasDevOpsAppSecret are present and current.
  • If using -MainMongoDbType AzureDocumentDb, Atlas-specific variables are not required.
  • Confirm the parameter wrapper script generates the current files required by the deployment stage:
    • Bicep/parameters-1.bicepparam
    • Bicep/parameters-2.bicepparam
    • ProvisionMongoAtlas.parameters.json (Atlas topology only)

Related deployment guide sections:

3) Confirm release pipeline task configuration

In Deploy Brief Connect Azure Resources, confirm that the target stage includes:

  • A PowerShell task that runs Generate[EnvName]Params.ps1.
  • An Azure CLI task that runs Scripts/ProvisionInfra.ps1.
  • The correct topology argument:
    • Atlas: -MainMongoDbType Atlas -AtlasDevOpsAppSecret (ConvertTo-SecureString "$(AtlasDevOpsAppSecret)" -AsPlainText -Force)
    • Azure DocumentDB: -MainMongoDbType AzureDocumentDb
  • A linked variable group for the target environment stage.

Related deployment guide section:

4) Run the infrastructure deployment pipeline

  1. Save your pipeline updates.
  2. Create a new release for the target environment stage.
  3. Run the stage and wait for completion.

Related deployment guide section:

5) Validate post-deployment outcomes

  • Confirm managed identity-based settings exist for MongoDB Atlas or Azure DocumentDB (MongoDB), Azure Managed Redis, and Azure Storage accounts for your selected topology.
  • Confirm core application access and connectivity: sign-in, dashboard load, opening a record, and basic search/filter actions.
  • Confirm migration and platform health checks complete successfully in Admin Health.

Related deployment guide sections:

6) Delete legacy Azure Cache for Redis resource

Delete the legacy Azure Cache for Redis resource from the environment resource group only after:

  • Step 5 validation is complete.
  • The deployment outcome is confirmed stable.
  • You confirm rollback is not required.

If rollback might still be required, delay this deletion step for an agreed observation window.

Rollback steps

Use this rollback only if the infrastructure upgrade cannot be stabilized in the target environment.

  1. Re-run the previous known-good Azure infrastructure release for the same environment (the last successful pre-2.6.x infrastructure state).
  2. Restore the previous environment parameter files and pipeline variable group values used by that known-good release.
  3. Re-apply all previous application settings for both Function App and API Web App, including settings changed in this release (MongoDB, Redis, Azure Storage account, and managed identity flags).
  4. Restore any previous Key Vault secret values and references that were replaced as part of this release.
  5. Redeploy the previous application package version only if required by your rollback plan.
  6. Run post-deployment smoke testing to confirm sign-in, dashboard, record access, search/filter, and admin health checks are working.

Related deployment guide sections: