Dell Command | Secure BIOS Configuration - SaaS Offer via Microsoft Azure Marketplace

Affected Products:

• Dell Command | Secure BIOS Configuration
• Dell Commercial Client Devices (Laptops, Desktops, Workstations)

Table of Contents:

• Introduction
• Deployment Model -- Customer-Hosted on Azure
• DCSBC Cloud vs. DCSBC On-Premises (DCC)
• Infrastructure as Code (Terraform)
• Prerequisites
• Getting Started -- Accessing the DCSBC Cloud Portal
• Creating BIOS Policies
  • Authentication Policy Workflow
  • BIOS Settings Policy Workflow
  • Deprovisioning Policy Workflow
• Certificate Requirements and Upload
• Publishing Policies to Microsoft Intune
• Security Controls
• FAQs

Introduction

Manageability interfaces rely on open interfaces, or password-authenticated commands. Password authentication is vulnerable to brute-force or dictionary attack, hence less secure compared to key-based authentication. A better authenticated manageability interface is needed to provide integrity and confidentiality protections of the data and commands. Dell Command | Secure BIOS Configuration (DCSBC) is an approach to move away from authenticating DACI commands with BIOS passwords. DCSBC provides trusted communication by creating an interface that uses PKI (Public Key Infrastructure) authentication mechanisms, and encrypted channels to pass messages between the platform and a client. This approach provides both integrity and confidentiality to protect customer data.
DCSBC Cloud extends this capability to a cloud-hosted SaaS model deployed into the customer's own Azure subscription. Instead of installing and maintaining a DCSBC server on-premises with Dell Command | Configure(DCC), IT administrators access a web-based portal hosted within their own Azure environment. The entire infrastructure is provisioned automatically via Terraform (Infrastructure as Code). Policies are created through a guided step-by-step web portal and published directly to Microsoft Intune -- with no local server setup, no Self-Contained Executable (SCE) generation, and no endpoint agent installation required.

Key Benefits of DCSBC Cloud:

• Customer owns their data -All infrastructure runs in the customer's Azure subscription. BIOS policies, cryptographic keys, configuration data, and audit logs remain under the customer's complete ownership and control. Dell does not have access to customer data.
• Data sovereignty and compliance - Customers choose the Azure region for deployment, ensuring data residency requirements are met. All data stays within the selected region.
• Infrastructure as Code - The entire solution is provisioned via Terraform, providing repeatable, auditable, and version-controlled infrastructure deployments.
• No on-premises infrastructure - Eliminates the need to install and maintain a DCSBC server with Dell Command | Configure.
• Web-based policy management - Create and manage BIOS policies from any browser using an intuitive step-by-step wizard.
• Native Intune integration - Policies are published directly to Microsoft Intune as Win32 LOB apps with a single click.
• Agentless deployment - No agent required on endpoints. The deployed package is self-contained.
• Azure Managed HSM signing - All BIOS payloads are cryptographically signed using Azure Managed HSM (RS384), ensuring only authorized changes reach devices.
• Zero-trust architecture - Trust exists only between the BIOS and the DCSBC Cloud service; no trust is required on the client/endpoint.
• Built-in replay attack prevention - Every BIOS session uses unique cryptographic nonces and ephemeral key exchanges, ensuring that previously captured payloads cannot be reused or replayed against devices.
• Cryptographically device-bound payloads - BIOS configuration payloads are cryptographically bound to each individual device during session establishment, preventing payloads intended for one device from being applied to another.

Back to Top

Deployment Model -- Customer-Hosted on Azure

Unlike traditional SaaS offerings where the vendor hosts the infrastructure, DCSBC Cloud is deployed into the customer's own Microsoft Azure subscription. This architecture provides several critical advantages:

• Data Ownership and Control: All Azure resources -- compute, storage, database, HSM, networking -- are provisioned within the customer's Azure tenant and subscription. BIOS policy configurations, cryptographic signing keys, session data, and audit logs are stored in the customer's own Azure SQL Database, Azure Key Vault / Managed HSM, and Azure Storage Account. Dell Technologies does not have access to the customer's data, keys, or infrastructure. The customer retains full administrative control.
• Data Sovereignty and Compliance: The customer selects the Azure region for deployment (e.g., East US 2, West Europe, Australia East). All resources are provisioned within that single region.
  Storage uses Locally Redundant Storage (LRS) by default, ensuring data does not leave the selected region. This can be configured to Geo-Redundant Storage (GRS) or Zone-Redundant Storage (ZRS) based on the customer's requirements. The customer-hosted model supports compliance with data residency regulations (GDPR, data sovereignty laws, industry-specific mandates) since the customer controls where data resides.
• Tenant Isolation: Each customer gets a fully isolated deployment: their own Resource Group, Virtual Network, subnets, databases, key vaults, and all other resources. Network isolation is enforced through private endpoints, Network Security Groups, and Azure Firewall.
• Cost Transparency: All Azure resource costs appear in the customer's own Azure billing, providing full visibility into infrastructure spend. The customer can leverage existing Azure commitments (MACC -- Microsoft Azure Consumption Commitment) and reserved instances.

Back to Top

DCSBC Cloud vs. DCSBC On-Premises (DCC)

Note:
Both solutions share the same underlying BIOS-level protocol, including session-based commands with Diffie-Hellman key exchange, nonce-based replay protection, and PKI authentication. Policies created with either solution are compatible with the same Dell commercial client BIOS implementations.

Back to Top

Infrastructure as Code (Terraform)

The entire DCSBC Cloud infrastructure is provisioned using Terraform(HashiCorp), providing repeatable, auditable, and version-controlled deployments. The Terraform configuration is modular and parameterized, allowing each customer deployment to be customized for their Azure region, naming conventions, and scale requirements.
Terraform Configuration Overview:

• Terraform version: >= 1.3.0
• AzureRM provider: ~> 4.37.0
• State management: Remote state stored in Azure Storage Account (Azure AD auth)
• Azure Resources Provisioned: The following resources are automatically provisioned into the customer's Azure subscription:

Back to Top

Prerequisites

Before using DCSBC Cloud, ensure the following prerequisites are met:

• Microsoft Azure Subscription - An active Azure subscription with an Azure Entra ID (Azure AD) tenant.
• Microsoft Intune - An active Microsoft Intune environment configured for device management.
• Dell Commercial Client Devices - Target devices must be Dell commercial laptops, desktops, or workstations with DCSBC-capable BIOS, enrolled in Microsoft Intune.
• Azure Managed HSM or Azure Key Vault - An Azure Managed HSM or Key Vault instance provisioned with RSA-HSM keys that correspond to the certificates used for BIOS authentication. The private key must reside in the HSM; only the public certificate (.pem) is uploaded to the DCSBC Cloud portal.
• X.509 Certificates - RSA certificates meeting the following requirements:
  • Key length: 3072-bit RSA (exactly)
  • Format: PEM (.pem file extension)
  • Version: X.509 v3
  • File size: Maximum 8 KB
  • Algorithm: RSA (OID 1.2.840.113549.1.1.1)
• Supported Browser - A modern web browser (Microsoft Edge, Google Chrome, Mozilla Firefox).

Back to Top

Getting Started -- Accessing the DCSBC Cloud Portal

• Subscribe - Purchase Dell Command | Secure BIOS Configuration Cloud through the Microsoft Azure Marketplace.
• Sign In - Navigate to the DCSBC Cloud portal URL provided upon subscription. Sign in with your Microsoft Entra ID (Azure AD) credentials. The portal uses Microsoft Authentication Library (MSAL) for single sign-on.
• Landing Page - After authentication, you are directed to the BIOS Policies dashboard. From here you can:
  • View existing BIOS policies published to your Intune tenant
  • Create a new policy using the step-by-step web portal

Back to Top

Creating BIOS Policies

From the BIOS Policies page, click Create a new policy. You will see three policy types:

Select a policy type to begin the guided wizard. These policies deploy directly from Intune to your endpoints without requiring installation of any endpoint agents.

Note:

At any given instance, only one provisioning key can be provisioned on a client machine.

Note:

Up to seven command keys can be provisioned on a client machine at any given instance.

Authentication Policy Workflow

The Authentication Policy wizard has 3 steps:

Step 1 -- Name Your Policy

• Enter a policy name (required, max 488 characters). A prefix AUTH_ and a timestamp suffix _DD.MM.YY_HH:mm_UTC are added automatically.
• Enter an optional description (max 1000 characters).
• The full policy name (including prefix and suffix, max 512 characters) is previewed before proceeding.
• Duplicate policy names are detected automatically by checking against existing published policies in Intune.

Step 2 -- Manage BIOS Security (Certificate Upload)

• Upload up to 3 certificates total:
  • 1 Provisioning certificate (required) -- used to authenticate secure connectivity for provisioning operations.
  • Up to 2 Command certificates-- used to sign payloads for BIOS configuration changes.
• For each certificate, select: 
  • Type: Provisioning or Command
  • Policy action: Add (provision a new key)
• Certificates are validated client-side (see Certificate Requirements and Upload).
• The Next button becomes enabled when:
  • A provisioning certificate is uploaded
  • 1 Command certificate is uploaded

Step 3 -- Review and Publish

• Review the policy name, description, and type.
• Click Publish to publish the policy to Microsoft Intune (see Publishing Policies to Microsoft Intune).

Back to Top

BIOS Settings Policy Workflow

The BIOS Settings Policy wizard has 4 or 5 steps(depending on whether existing BIOS policies exist in Intune):

Step 1 -- Copy and Edit, or Start from Scratch(conditional -- only shown if existing policies exist)

• Start a blank policy file -- Begin with an empty configuration.
• Copy then edit -- Copy BIOS attribute values from an existing published policy and modify them. A modal shows a searchable, sortable, paginated list of existing BIOS policies.

Step 2 -- Name Your Policy

• Same as Authentication Policy, but with the BIOS_ prefix.

Step 3 -- Choose BIOS Attributes and Values

• A table displays all available BIOS attributes from the Dell attribute registry.
• Search for attributes by name, filter by category, and toggle to show only selected attributes.
• Select an attribute by clicking its checkbox, then configure its value:
  • Enum attributes (e.g., SecureBoot, WakeOnLan) -- Select from a dropdown of allowed values.
  • Integer attributes (e.g., AutoOnHr, CustomChargeStart) -- Enter a number within the min-max range.
  • String attributes (e.g., AssetTag) -- Enter text up to 80 characters.
  • Custom features (e.g., AutoOn scheduling, Battery charge configuration, Keyboard backlight color)-- Click "View/Change" to open a dedicated configuration modal.
• A Code Preview panel shows a live preview of the selected configuration in CCTK format:

[cctk]

SecureBoot=Enabled

WakeOnLan=LanOnly

AutoOn=SelectDays

AutoOnMon=Enabled

AutoOnTue=Enabled

• The Next button is disabled if no attributes are selected or any selected attribute has an invalid value.

Step 4 -- Manage BIOS Security

• Upload the same Command certificate that was used for the Authentication policy.
• One Command certificate is required to proceed.

Step 5 -- Review and Publish

• Review and publish to Microsoft Intune.

Back to Top

Deprovisioning Policy Workflow

The Deprovisioning Policy wizard has 3 steps:

Step 1 -- Name Your Policy

• Same as other policies, with the DPRV_ prefix.

Step 2 -- Manage BIOS Security

• Upload the same Provisioning certificate that was used for the Authentication policy.
• One Provisioning certificate is required.
• Note: Expired certificates are permitted for deprovisioning operations, since the purpose is to remove provisioning from devices.

Step 3 -- Review and Publish

• Review and publish. The deprovisioning policy uses a Clear DACI operation to remove all provisioned keys from the target devices.

Back to Top

Certificate Requirements and Upload

DCSBC Cloud requires X.509 certificates in PEM format for signing BIOS payloads. The private key must be stored in Azure Managed HSM or Azure Premium Key Vault; only the public certificate is uploaded to the DCSBC portal.

Certificate Validation Rules:

Validation is performed client-side. After a certificate is uploaded, the portal displays:

• Validation status badge (Success / Failed)
• Issued on date
• Valid till date (shown in red if expired)
• Issuer details: Common Name (CN), Organizational Unit (OU), Organization (O), Location (L)

Error Messages:

• "Please upload a valid .pem file." -- File is not in PEM format or has wrong extension.
• "File name contains invalid characters." -- File name contains spaces or special characters.
• "File max size is 8KB" -- File exceeds the 8 KB limit.
• "This file is invalid, corrupted, or empty. Select another file with a valid x509 certificate and try again." --Certificate could not be parsed or fails X.509 v3 / RSA / 3072-bit validation.
• "This certificate cannot be used." -- Certificate is expired and policy action is "Add."

Back to Top

Publishing Policies to Microsoft Intune

After completing the policy wizard, click the Publish button in the Review and Publish step. The portal executes an automated 11-stage publishing pipeline:

A progress bar and detailed stage tracker show real-time publishing status. Upon successful completion:

• The message "The {policyName} policy has been published to Intune and will be available within a few minutes" is displayed.
• View in Intune -- Opens the Microsoft Intune admin portal in a new tab.
• Back to Policies -- Returns to the BIOS Policies dashboard.

Error Handling: If any stage fails, an error message is displayed with a Retry button (up to 3 retries). Common errors include Intune API timeouts, storage upload failures, and file commit delays.

Back to Top

Security Controls

DCSBC Cloud implements defense-in-depth security across all layers of the infrastructure. Since the solution runs in the customer's Azure subscription, all security controls are auditable and under the customer's governance.

Network Security:

• Private Endpoints ensure that traffic between Azure services (database, key vault, HSM, storage, app services) never traverses the public internet.
• Public network access is disabled by default for all data-plane services. Only the API gateway and CDN endpoints are publicly accessible.
• Network Security Groups (NSGs) control inbound and outbound traffic for each subnet with granular rules.
• Virtual Network isolation -- All resources are deployed within a single VNet with segregated subnets for each service tier.

Application Security:

• Web Application Firewall (WAF) with industry-standard OWASP managed rule sets in Prevention mode, providing protection against common web exploits (SQL injection, XSS, etc.).
• CDN-level firewall provides an additional WAF layer at the edge.
• API rate limiting -- Per-operation, IP-based rate limiting protects backend services from abuse and denial-of-service attacks.
• Azure AD JWT token validation -- All API calls are validated for Azure AD authentication tokens, ensuring only authorized users can access backend services.
• CORS restrictions -- Cross-origin requests are restricted to authorized origins only.

Encryption:

• TLS 1.2 minimum enforced across all services with only strong cipher suites permitted.
• Azure Managed HSM -- Cryptographic signing operations use FIPS 140-2 Level 3 validated hardware security modules, ensuring keys are never exposed in software.
• Data at rest is encrypted using Azure platform encryption across all storage services.

Identity and Access:

• Managed Identities (zero stored credentials) -- Azure Managed Identities are used for all service-to-service authentication. No passwords, connection strings, or secrets are stored in application configuration.
• RBAC least-privilege -- Each managed identity is assigned only the minimum required roles, following the principle of least privilege.
• Azure Bastion -- Secure administrative access to management VMs without exposing public IPs.

Monitoring and Alerting:

• Automated alerts for critical security and operational events, including rate limiting violations, backend errors, unauthorized access attempts, WAF blocking patterns, API latency anomalies, and HSM signing failures.
• Comprehensive diagnostic logging across all infrastructure components -- API gateway, application gateway, web applications, database, key vault, and HSM -- with logs collected in a centralized Log Analytics workspace.
• Dashboards for real-time operational visibility and trend analysis.

Governance:

• Pre-deployment policy checks (OPA-based) enforce security baselines before infrastructure is provisioned, including public network access restrictions, minimum TLS versions, purge protection requirements, and public IP controls.
• Resource locks prevent accidental deletion of critical data stores (key vaults, databases, storage accounts).

Back to Top

FAQs

Q: I already use DCSBC with Dell Command | Configure on-premises. Can I migrate to DCSBC Cloud?

Yes. Both solutions use the same underlying BIOS-level protocol (DACI with PKI authentication). Devices provisioned with the on-premises solution can be managed by DCSBC Cloud and vice versa, as long as the same certificates/keys are used. You will need to upload your existing certificates to the DCSBC Cloud portal and ensure the corresponding private keys are available in Azure Managed HSM or Key Vault.

Q: Where does DCSBC Cloud run? Is it hosted by Dell?

No. DCSBC Cloud is deployed into your own Microsoft Azure subscription. All infrastructure -- compute, storage, database, HSM, networking -- runs in your Azure tenant. Dell does not host or have access to your data or infrastructure. The entire solution is provisioned automatically using Terraform.

Q: Does Dell have access to my BIOS policies, keys, or configuration data?

No. Since DCSBC Cloud runs entirely within your Azure subscription, all data remains under your ownership and control. Dell provides the software and Terraform templates, but does not access, store, or process your data.

Q: Can I choose which Azure region to deploy in?

Yes. The Azure region is a parameter in the Terraform configuration. You can deploy to any supported Azure region to meet your data residency and compliance requirements. All resources are provisioned within the single selected region.

Q: Do I need to install Dell Command | Configure on the DCSBC Cloud server?

No. There is no on-premises server. The infrastructure is provisioned in your Azure subscription via Terraform, and the application runs as Azure-managed services (App Service, Function App, Static Web App).

Q: Do I need to install any Dell software on the endpoint devices?

No. The .intunewin packages deployed via Intune are self-contained and include all necessary components. No endpoint agent installation is required.

Q: What deployment consoles are supported?

DCSBC Cloud currently supports Microsoft Intune as the deployment console. The on-premises DCSBC with DCC additionally supports SCCM and WorkspaceONE.

Q: Can I use my own HSM provider instead of Azure Managed HSM?

DCSBC Cloud is designed to work with Azure Managed HSM or Azure Key Vault. If you require a different HSM provider, consider using the on-premises DCSBC with DCC, which supports vendor-agnostic HSM via the configurable HSMSigning.bat script.

Q: What RSA key sizes are supported?

DCSBC Cloud requires exactly 3072-bit RSA keys. Keys of other sizes (2048-bit, 4096-bit, etc.) will be rejected during certificate validation.

Q: Can I use the same certificate for both the on-premises and cloud DCSBC solutions?

Yes, as long as the private key is accessible in both environments -- stored in your local HSM/certificate store for the on-premises solution, and in Azure Managed HSM or Key Vault for the cloud solution.

Q: What happens if my certificate expires?

Expired certificates cannot be used for "Add" (provisioning) operations. However, expired certificates are accepted for Deprovisioning operations, since the intent is to remove provisioning from devices.

Q: What BIOS settings can I configure?

DCSBC Cloud includes a comprehensive BIOS attribute registry covering categories such as Security, Power and Performance Management, System Configuration, Video, and Advanced Configurations. Examples include SecureBoot, WakeOnLan, Boot Order, AutoOn scheduling, Battery Charge Configuration, Keyboard Backlight Color, and many more.

Q: What Terraform version is required to deploy DCSBC Cloud?

Terraform >= 1.3.0 is required, with the AzureRM provider ~> 4.37.0.

Q: Can I customize the Terraform deployment (e.g., SKU sizes, scaling, storage redundancy)?

Yes. The Terraform configuration is fully parameterized via variables. You can customize the App Service Plan SKU, database tier, storage replication type (LRS/GRS/ZRS), Application Gateway auto scale settings, and more based on your scale and availability requirements.