We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Microsoft security
  3. Azure Key Vault
Azure Key Vault, UAE

The connection string in the config file is the finding every audit opens with. This is the answer to it.

Key Vault stores secrets, keys and certificates so applications retrieve them by URI at runtime instead of carrying them in code or configuration. Two tiers, one authorisation decision that most estates get wrong, and a topology question that determines whether one compromised application exposes everything or only itself.

Book a secrets management reviewSee what belongs in a vault
Azure Key Vault secrets and certificate management for UAE organisations
  • Two tiersFIPS 140 Level 1 software, or Level 3 HSM
  • RBAC or policyThe authorisation decision worth getting right
  • Vault per applicationThe topology that limits blast radius
  • Auto renewalFor certificates from public authorities
What it does

Eight things that decide whether your vault design holds up.

Microsoft frames Key Vault around three problems: securely storing and tightly controlling access to tokens, passwords, certificates, API keys and other secrets; creating and controlling the encryption keys used to encrypt data; and provisioning, managing and deploying public and private TLS certificates for Azure and internally connected resources.

Secrets retrieved by URI, not stored in the application

Microsoft describes applications securely accessing what they need using URIs that allow retrieval of specific versions of a secret, with no custom code needed to protect the secret. The published example is the one every audit finds: a database connection string that lives in the application code, which instead lives in the vault and is fetched at runtime.

Two tiers, and the difference is where the key lives

Standard tier encrypts data using software libraries validated to FIPS 140 Level 1. Premium tier offers HSM-protected keys generated and protected by FIPS 140-3 Level 3 validated Marvell LiquidSecurity hardware security modules. Microsoft states Premium HSM-protected keys, in RSA-HSM, EC-HSM or OCT-HSM form, never leave the HSM boundary. That distinction is what a regulator asks about.

RBAC or access policy, and they are not equivalent

Authentication is through Microsoft Entra ID. Authorisation is either Azure role-based access control or a Key Vault access policy, and Microsoft draws the distinction precisely: Azure RBAC can be used both for management of the vaults and to access the data stored in them, whereas a key vault access policy can only be used when accessing data. That is why RBAC is the model to standardise on.

Certificates, including automatic enrolment and renewal

Key Vault provisions, manages and deploys public and private TLS certificates for Azure and internally connected resources, and Microsoft names automating certain tasks on certificates purchased from public certificate authorities, such as enrolment and renewal. In UAE estates the expired certificate outage is a recurring event, and this is the control that ends it.

A vault per application, which is the whole blast radius argument

Microsoft describes segregating application secrets so applications access only the vault they are permitted to, limited to specific operations, and states you can create a Key Vault per application and restrict the secrets in it to that application and its development team. One shared vault holding everything is the design that turns one compromised service principal into a full estate incident.

Logging, to three destinations you choose

Monitoring is enabled per vault, with logs archived to a storage account, streamed to an event hub, or sent to Azure Monitor logs. Microsoft also notes you control those logs, can secure them by restricting access, and can delete logs you no longer need. Knowing who read which secret and when is what makes a vault auditable rather than merely secure.

Replication and failover with nothing for you to do

Microsoft describes replicating vault contents within a region and to a secondary region, stating that replication ensures high availability and takes away the need for any administrator action to trigger failover. For a control that sits directly in the runtime path of every application that uses it, availability is not an optional consideration.

It plugs into the Azure services that need keys anyway

Microsoft names Azure Disk Encryption, the Always Encrypted and Transparent Data Encryption features in SQL Server and Azure SQL Database, and Azure App Service. Key Vault itself integrates with storage accounts, event hubs and log analytics. Customer-managed key scenarios almost always route through a vault, which is why the design decisions here propagate widely.

The decision that outlives the project

Azure RBAC or access policies. Pick once, and pick RBAC.

Microsoft describes both models neutrally, but the difference in what each can express is what should decide it.

  • Quoted: Azure RBAC can be used for both management of the vaults and to access data stored in a vault, while key vault access policy can only be used when attempting to access data stored in a vault.
  • That means a policy-based vault needs two separate mechanisms to express who can administer it and who can read from it, which is exactly the split where permissions drift apart over a few years.
  • RBAC also inherits the tooling everything else in Azure already uses: role assignments visible in the same place, reviewable in the same reports, and manageable through the same access review process rather than a per-vault list somebody maintains by hand.
  • Mixed estates are the common finding. Vaults created at different times under different models, with nobody able to answer who can read production secrets without opening each vault individually. Standardising is unglamorous and it is the highest value thing we change.
Ask us to audit your vault permissions
How we approach it

Four things that turn a vault into an actual control.

Creating a Key Vault takes two minutes. Getting every secret out of every configuration file, keeping them out, and being able to answer who can read production secrets is a programme rather than a task.

We standardise on one authorisation model

Azure RBAC, because Microsoft states it covers both management of the vaults and access to the data inside them, whereas an access policy covers data access only. A mixed estate cannot answer who can read production secrets without inspecting each vault by hand, and that is exactly the question an auditor asks.

We design vault topology for blast radius, not convenience

Microsoft describes a Key Vault per application with its secrets restricted to that application and its development team. One shared vault is easier to set up and turns a single compromised service principal into an estate-wide incident. Splitting by application and by environment costs a little effort once and pays every time something goes wrong.

We rotate what was exposed rather than just relocating it

A secret that has ever been committed to source control is compromised, and moving it into a vault does not change that. The migration inventory separates secrets that can simply move from secrets that must be rotated as they move, and that distinction is what makes the exercise a remediation rather than a filing task.

We route the logs somewhere somebody looks

Microsoft supports archiving to a storage account, streaming to an event hub, or sending to Azure Monitor logs. Which of the three matters less than whether unusual read activity reaches a queue that is worked. A vault whose access log nobody has ever queried is a storage improvement rather than a security control.

Where this matters most

Six UAE situations where a vault design earns its keep.

Microsoft frames Key Vault within Zero Trust, noting that data protection including key management supports the use least privilege access principle. In practice, the triggers are usually an audit finding, a certificate outage or a customer requirement.

A regulated firm asked where its encryption keys live

This is where the tier decision becomes a compliance answer rather than a technical preference. Premium tier keys are generated and protected by FIPS 140-3 Level 3 validated hardware security modules and, as Microsoft states, never leave the HSM boundary. Standard tier uses software libraries validated to FIPS 140 Level 1. Which you need depends on the obligation, and it should be a documented decision.

A business that has just failed an audit on secrets handling

The finding is nearly always the same: credentials in configuration files, in deployment pipelines, or in a document somebody shares. Moving them into a vault, retrieved by URI at runtime, closes the finding. Rotating the ones that were ever in source control is what makes the closure honest rather than cosmetic.

An organisation that has had a certificate expiry outage

Usually more than one. Key Vault manages public and private TLS certificates and automates enrolment and renewal for certificates purchased from public authorities. Combined with integration into Azure App Service, that removes the specific class of outage that occurs at three in the morning because a calendar reminder was set by someone who has since left.

A development team building on Azure at pace

Secrets accumulate faster than governance does, and by the time anybody looks there are four hundred of them in twelve places. Establishing a vault per application, with managed identities where the platform supports them so there is no bootstrap secret at all, is far cheaper as a starting convention than as a retrofit.

A group implementing customer-managed keys

Azure Disk Encryption, Always Encrypted and Transparent Data Encryption in SQL Server and Azure SQL Database all route through a vault, as Microsoft names directly. Once customer-managed keys are in play, vault availability, replication and access control stop being a security topic and become an application availability topic too.

An organisation formalising a Zero Trust programme

Microsoft frames key management explicitly within Zero Trust, noting that data protection supports the use least privilege access principle alongside verify explicitly and assume breach. A vault estate with per-application segregation, RBAC, and logged access is one of the clearer pieces of evidence that least privilege has been applied to something other than user accounts.

Three positions

How UAE organisations store application secrets today.

The middle column is the honest state of most estates. A vault exists, some things are in it, and the connection strings in the older applications never moved because nobody had time.
Secrets out of source control
Designed vault estateYes
A vault exists, partially usedPartly
Config files and shared spreadsheetsNo
Retrieved at runtime by URI
Designed vault estateYes
A vault exists, partially usedPartly
Config files and shared spreadsheetsNo
One authorisation model estate-wide
Designed vault estateYes
A vault exists, partially usedNo
Config files and shared spreadsheetsNot applicable
Blast radius limited per application
Designed vault estateYes
A vault exists, partially usedNo
Config files and shared spreadsheetsNo
Certificate renewal automated
Designed vault estateYes
A vault exists, partially usedRarely
Config files and shared spreadsheetsNo
HSM-protected keys where required
Designed vault estateYes
A vault exists, partially usedUnknown
Config files and shared spreadsheetsNo
Access logged and reviewed
Designed vault estateYes
A vault exists, partially usedLogged only
Config files and shared spreadsheetsNo
Rotation actually happens
Designed vault estateYes
A vault exists, partially usedNo
Config files and shared spreadsheetsNo
Managed identities used where possible
Designed vault estateYes
A vault exists, partially usedSometimes
Config files and shared spreadsheetsNo
Audit finding on secrets handling
Designed vault estateClosed
A vault exists, partially usedOpen
Config files and shared spreadsheetsOpen
Feature
Designed vault estate
A vault exists, partially used
Config files and shared spreadsheets
Secrets out of source control
YesPartlyNo
Retrieved at runtime by URI
YesPartlyNo
One authorisation model estate-wide
YesNoNot applicable
Blast radius limited per application
YesNoNo
Certificate renewal automated
YesRarelyNo
HSM-protected keys where required
YesUnknownNo
Access logged and reviewed
YesLogged onlyNo
Rotation actually happens
YesNoNo
Managed identities used where possible
YesSometimesNo
Audit finding on secrets handling
ClosedOpenOpen
What goes where

Three object types, and the design question attached to each.

Object types and capabilities as published. The design question column is ours, and it is the one that determines whether the vault is genuinely used.
Object typeWhat Microsoft says it coversThe design question
SecretsTokens, passwords, certificates, API keys and other secrets, stored and tightly access controlledWhich application owns each one, and what rotates it when it changes
KeysCreating and controlling the encryption keys used to encrypt your dataStandard software-protected, or Premium HSM-protected keys that never leave the HSM boundary
CertificatesProvisioning, managing and deploying public and private TLS certificates for Azure and internal resourcesWhich are issued by a public authority and can be auto-enrolled and auto-renewed
Vault topologyA Key Vault per application, restricting its secrets to that application and development teamHow many vaults, split by application, environment, or both
AuthenticationThrough Microsoft Entra ID, for both users and applicationsManaged identities rather than secrets, wherever the platform supports it
AuthorisationAzure RBAC for management and data access, or access policy for data access onlyOne model across the estate, not one per vault creation date
MonitoringArchive to a storage account, stream to an event hub, or send to Azure Monitor logsWhere the logs land, and who actually reviews unusual read patterns
AvailabilityReplicated within a region and to a secondary region, with no administrator action to fail overWhether every dependent application handles a transient failure gracefully
How an engagement runs

Five steps, and the inventory is the unglamorous majority.

Typically six to twelve weeks depending on how many applications are in scope. Standing up vaults is quick. Finding every secret, deciding which must be rotated, and changing the applications to fetch at runtime is the work.
  1. 1

    Inventory secrets, keys and certificates

    Configuration files, deployment pipelines, scripts, shared documents and the application source itself. Each item gets an owner, an application, and a flag for whether it has ever been in source control, because those must be rotated as part of the migration rather than simply relocated.

  2. 2

    Decide tier, topology and authorisation model

    Standard tier with FIPS 140 Level 1 software libraries, or Premium tier with FIPS 140-3 Level 3 validated hardware security modules, decided against the actual obligation. A vault per application per environment. Azure RBAC as the single authorisation model across the estate, because it covers both management and data access.

  3. 3

    Migrate, rotating what needs rotating

    Applications changed to retrieve by URI at runtime rather than reading local configuration, using managed identities wherever the platform supports them so there is no bootstrap secret to protect. Certificates from public authorities moved onto automated enrolment and renewal so the expiry class of outage disappears.

  4. 4

    Wire the monitoring and prove it works

    Logging enabled per vault to a storage account, an event hub or Azure Monitor logs. Then an actual test: an unexpected read pattern generated deliberately, and a check that it reaches somebody. Logging that has never produced an alert has never been verified.

  5. 5

    Hand over the operating model

    Who approves a new vault, how a developer requests access, what rotates each secret and on what schedule, and who reviews access on the same cycle as the rest of your identity governance. Without those four answers, a well-built vault estate drifts back towards configuration files within about two years.

Straight answers

What organisations ask about Azure Key Vault.

Microsoft describes three categories. Secrets, covering tokens, passwords, certificates, API keys and other secrets. Keys, for creating and controlling the encryption keys used to encrypt your data. And certificates, for provisioning, managing and deploying public and private TLS certificates for use with Azure and your internal connected resources.

Standard encrypts data using software libraries validated to FIPS 140 Level 1. Premium offers HSM-protected keys generated and protected by FIPS 140-3 Level 3 validated Marvell LiquidSecurity hardware security modules, in RSA-HSM, EC-HSM or OCT-HSM form, which Microsoft states never leave the HSM boundary. The right answer follows your obligation, so we document the decision rather than defaulting to either.

RBAC, in almost every case. Microsoft states Azure RBAC can be used both for management of the vaults and to access data stored in a vault, while a key vault access policy can only be used when accessing data. That means RBAC expresses the whole permission picture in one model, and it integrates with the access review and reporting you already run for the rest of Azure.

By URI. Microsoft describes applications securely accessing what they need using URIs that allow retrieval of specific versions of a secret, with no custom code required to protect the secret information. Combined with a managed identity for authentication, that means an application can hold no credential at all and still read what it needs at runtime.

More than one. Microsoft states that applications may access only the vault they are allowed to access and can be limited to specific operations, and that you can create a Key Vault per application, restricting the secrets in it to that application and its team of developers. One shared vault is the design that turns a single compromised identity into an estate-wide problem.

Microsoft states directly that Azure Key Vault is designed so that Microsoft does not see or extract your data. All key vaults are encrypted at rest using keys stored in hardware security modules, and the Premium tier adds HSM-protected keys that never leave the HSM boundary. Whether that satisfies a specific regulatory obligation is a separate question we would work through with you.

Microsoft describes replicating the contents of your Key Vault within a region and to a secondary region, stating that data replication ensures high availability and takes away the need for any administrator action to trigger failover. The consideration on your side is that applications should handle transient failures gracefully, since a vault sits in the runtime path of everything using it.

Yes, and this is often the fastest win. Key Vault provisions, manages and deploys public and private TLS certificates, and Microsoft names automating certain tasks on certificates purchased from public certificate authorities, including enrolment and renewal. Integration with Azure App Service means a renewed certificate can flow through without a manual step, which ends the expiry outage.

Microsoft names Azure Disk Encryption, and the Always Encrypted and Transparent Data Encryption functionality in SQL Server and Azure SQL Database, as scenarios Key Vault simplifies. Customer-managed key arrangements generally route through a vault, which means the vault design decisions propagate into the availability and access model of those services too.

Yes, once logging is enabled per vault. Microsoft lists three destinations: archive to a storage account, stream to an event hub, or send the logs to Azure Monitor logs. It also notes you control those logs, can secure them by restricting access, and can delete ones you no longer need. The thing worth deciding is not where they go but who reviews unusual access.

It makes it safer, and it does not undo prior exposure. A secret that has ever been committed to source control, sent by email or pasted into a shared document should be treated as compromised, which means the migration must rotate it rather than relocate it. Separating those two cases during the inventory is the difference between remediation and paperwork.

Yes. A vault stores and controls access to a secret, it does not change it on a schedule by itself. Deciding what rotates each secret, how often, and what happens to the applications that consume it during rotation is part of the design rather than an afterthought, and it is the part most commonly missing from vault deployments we assess.

Microsoft places it explicitly. Zero Trust comprises verify explicitly, use least privilege access, and assume breach, and Microsoft states that data protection including key management supports the use least privilege access principle. A vault estate segregated per application, with RBAC and logged access, is concrete evidence of least privilege applied to something beyond user accounts.

Six to twelve weeks in a typical estate, dominated by inventory and application changes rather than by the platform work. Standing up vaults and setting the authorisation model is days. Finding every secret in every configuration file, deciding which must be rotated, and changing applications to fetch at runtime is what fills the calendar.

We scope per organisation, driven by application count, whether Premium tier is required, and whether you want the application changes made or only specified. The most useful free step is usually the inventory conversation, because most organisations discover during it that they hold more secrets in more places than anybody had assumed.
Before you migrate secrets

Fifteen questions that make a vault deployment last.

The first group is inventory, and it is the part nobody wants to do. The second is design. The third is what happens after the migration project ends, which is where most vault deployments quietly decay.

Inventory

  • Where are secrets today?
    Config files, pipelines, scripts, somebody notes.
  • Which are in source control history?
    Those need rotating, not just moving.
  • Which certificates expire this year?
    Start with the ones that have caused outages.
  • Which keys protect customer data?
    That decides the tier conversation.
  • Who owns each application?
    Vault per application needs an owner per vault.

Design

  • Standard or Premium tier?
    FIPS 140 Level 1 software, or Level 3 HSM.
  • RBAC or access policies?
    RBAC covers management and data access.
  • How many vaults, and split by what?
    Per application is the published guidance.
  • Are environments separated?
    Production secrets should not sit beside test ones.
  • Can applications use managed identities?
    Then there is no bootstrap secret at all.

After the project

  • Where do the logs go?
    Storage, event hub or Azure Monitor.
  • Who reviews unusual read activity?
    A log nobody reads is not a control.
  • What rotates each secret, and how often?
    A vault does not rotate by itself.
  • Who approves a new vault?
    Otherwise sprawl starts within months.
  • How do developers get access?
    A process, or they will work around the vault.
Related reading

The pages around this one.

Azure security audit

The wider assessment where secrets handling findings usually originate.

Learn more

Azure cloud solutions

The platform work a vault estate sits inside.

Learn more

Microsoft Cloud PKI

Certificate issuance for devices, alongside vault-managed TLS certificates.

Learn more
Next step

Search your source control for the word password. Then call us.

That single search is the fastest way to find out whether this is a small piece of tidying or a remediation programme. In most organisations we work with, the result is more surprising than the team expects.

Book a secrets management reviewCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Azure Security Audit

Subscription audit, starting with the free tier you already own

Learn more

Azure Cloud Solutions

Azure landing zone, migration, FinOps, managed

Learn more

Microsoft Cloud PKI

Retire the certificate server, NDES and the Intune connector

Learn more

Defender for Cloud

Azure posture, and the free tier almost nobody has enabled

Learn more

Azure Migration

On-prem to Azure migration with landing zone setup

Learn more

IT General Controls

What your external auditor tests, and the evidence they sample

Learn more

Microsoft Security Dubai

Entra, Defender, Purview, Sentinel, and what you already own

Learn more

Microsoft Entra

Identity and access management solutions

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy