Use a supported secure output type when Bicep must return sensitive structured data

Source facts

Bicep 0.35.1 and later support @secure() on string and object outputs. Resource Manager treats these values as sensitive and suppresses them from deployment history, the portal and command-line output.

The decorator does not directly support arrays or numbers. Microsoft recommends wrapping such values in a secure object or serializing them as a secure string. Microsoft Learn.

Applicability

Check the actual Bicep version and every output consumer. Distinguish a secure type declaration from an ordinary array or number whose name merely suggests sensitivity.

DSE recommendation

DSE recommends avoiding unnecessary sensitive outputs first. Where an output is required, choose a supported secure representation and explicitly document its structure for the consumer. Review any downstream handling as a separate responsibility instead of assuming the declaration proves that an entire pipeline keeps the value confidential. Keep real credentials out of test examples and review records.

Verification

Use synthetic, nonsecret values to validate the declared type, compilation and consumer’s interpretation. Inspect deployment history, portal and command output in the approved test workflow for the documented suppression behavior. Review downstream diagnostics separately and confirm that changing an array to an object or string has not broken the expected contract. Preserve configuration evidence without copying an actual sensitive output into the ticket.

Official references

Microsoft Learn: Outputs in Bicep. Source retrieved September 9, 2026.