Skip to content

Enabling GovRAMP Compliance for a Public Safety Technology Company’s VR Device Registration Across Multi-Region Azure Infrastructure

Overview

A public safety technology company’s VR product regions faced a compliance deadline: GovRAMP required them to stop accessing ERP systems and Snowflake directly, yet devices still needed to be registrable globally the moment they shipped. The source of truth for device data lived in systems that product regions could no longer touch, and centralizing customer data would violate data-residency rules.

IntelliTect developer Benjamin Michaelis, working as the sole IntelliTect engineer, designed and implemented a device registration coordination system hosted in the company’s corporate Azure subscription. The system acts as an ERP extension so that ERP data never crosses the corporate boundary, while regional backends pull only the minimal information they need to register devices. The system spans multiple Azure regions and both government and non-government Azure clouds, and it is now in production actively enabling GovRAMP compliance with regions onboarding.

Challenges

GovRAMP compliance required that product regions stop depending directly on Snowflake, D365, and Salesforce. Any system built on those platforms is classified as an ERP extension and cannot reside in a product-region subscription. However, every device configured by the company still needed to be available globally for customer registration the moment it shipped. The source of truth for device serial numbers and availability lived in the very ERP systems regions could no longer access. Centralizing a single copy of customer data would break data-residency boundaries.

The system also needed to operate across multiple Azure regions and span both government and non-government Azure clouds, adding complexity to networking, authentication, and data flow. Additionally, double registration of devices across regions had to be prevented without making any single system fully authoritative over regional decisions.

Solution

The coordination system sits in the corporate Azure subscription as an ERP extension, ensuring ERP data never leaves the corporate boundary. Regional backends pull only what they need: serial number, availability, and routing information (country code and segment). Connections are secured with mTLS and IP allow-listing. Service Bus access is gated by a custom SAS-token broker built as part of the project. Regions maintain their own cached copies of device data and report claimed devices back to the coordination system to prevent double registration, though the system is not authoritative and regions can deviate. Data flows from Snowflake via Parquet exports to Blob Storage, where a scheduled parser job ingests it into the system’s database. A shared NuGet package was published to GitHub Packages for regional teams to consume.

Technical Approach and Architecture:

Benjamin Michaelis worked from a Technical Design Document authored by a company architect and translated it into a full implementation, contributing significantly to Azure-specific infrastructure decisions along the way. Key architectural choices included using Azure Application Gateways with mTLS instead of nginx containers for boundary security, designing the private networking and DNS topology, and implementing the Service Bus SAS-token authentication model via the custom token broker. The application consists of three components: the registration API (an ASP.NET Core web app with OpenAPI), the token broker (an ASP.NET Core SAS-token broker with OpenAPI), and the Parser (a scheduled Container Apps job that reads Parquet exports from Blob Storage). All infrastructure was designed and implemented in reusable Terraform modules supporting both dev and prod environments. CI/CD runs on GitHub Actions with private network runners, Terraform plan on pull requests and apply on merge, and tag-driven application deployments using blue/green Container Apps revisions with next and live traffic labels and health checks before traffic shifts. The system uses user-assigned managed identities and Entra authentication for a zero-credential design, with Key Vault for secrets and ACME certificates for mTLS. Observability is provided through OpenTelemetry integrated with Azure Monitor and Application Insights, with alerting wired to an on-call action group. Operator access is secured via Point-to-Site VPN on Virtual WAN.

Technologies Used

C# on .NET 10, ASP.NET Core with OpenAPI, EF Core with SQL Server and migrations, .NET Aspire, Azure SDKs (Service Bus, Blob Storage, Resource Manager, Identity), Docker, Azure Container Apps, Azure Application Gateway with mTLS, Azure Service Bus, Azure Key Vault, Azure SQL, Azure Blob Storage, Azure Container Registry, Azure Monitor and Application Insights, OpenTelemetry, User-assigned managed identities and Entra authentication, ACME certificates, Virtual WAN with Point-to-Site VPN, Terraform, GitHub Actions (private network runners, tag-driven blue/green deployments, Dependabot, Docker Buildx layer caching), TUnit, Verify snapshot tests, Aspire integration tests, GitHub Packages

Outcome

The coordination system is in production and actively enabling GovRAMP compliance for the company’s VR product regions. Production infrastructure was stood up with the prod stack added July 14, 2026, and prod deployment pipelines landed August 7, 2026. Blue/green revisions with health checks ensure safe traffic shifts before production traffic moves. Production is tuned for real consumers with region URL configuration, routing fixes, and alerting wired to an on-call action group. Active region onboarding is underway. The project reduced dependence on ArborXR and eliminated direct product-region access to Snowflake and ERP systems, satisfying GovRAMP’s core constraints.