When using the BYOK procedure, after uploading your HSM-generated key to the Key Vault there is zero traceability to confirm that what was uploaded in the cloud is actually what you have originally generated with your nCipher HSM.
The solution is very simple - nCipher HSMs already generate hashes for the generated keys in the security world metadata, AKV should store / display the hash after successful upload so you can verify your keys at any time.

Otherwise the following attack scenario is possible (if unlikely):

Prerequisites:
* Knowledge of the attack target's subscription ID (not particularly confidential information at large corporations using dozens of services under one subscription)
* Knowledge of the attack target's Azure region
* 1 compromised person in the BYOK-procedure chain
* Attacker's subscription in the appropriate region
* Attacker's own nCipher HSM

Attack procedure:
1. Generate key with attacker's HSM
2. Sign transfer package with target's subscription ID
3. Encrypt transfer package with appropriate Azure region key exchange keys
4. During the BYOK procedure (the key transfer packages are usually carried from the offline PAW to the online PAW on some kind of medium like a USB-stick) the compromised person or the attacker him- / herself swaps the target's transfer package with the attacker's transfer package (remember, it's signed for the target's subscription ID)
5. Key is uploaded to AKV with no positive traceability info and henceforth the attacker's key is used by the target to encrypt "whatever" without the target's having any possibility of knowing this

In my opinion this could be especially bad if a large company relied on AKV with BYOK in conjunction with Azure Information Protection to protect ALL their sensitive Mails and Documents.

TLDR: I want the possibility to overwrite already existing secrets with the Restore-AzKeyVaultSecret/Key/Certificate to allow for replication in the customers control.

According to the Key Vault documentation Azure Key Vault provides a 99.9% availability percentage and a replication to the pair region takes place to ensure customers can continue using their Key Vaults after a failover in read-only.

However this is a situation a customer does not and can not control. This means that a customer has to wait until Microsoft declares a disaster and fails over the vaults to the pair region. I would like it if we would be able to take more control of this process.

This can be made possible by being able to backup and restore secrets on a more continuous basis to another Key Vault which resides in the pair region. It is currently impossible to overwrite an already existing secret with a backup file if it already exists by name even though the backup has a newer version of the secret than the one already residing in the target Key Vault.

It should be possible to select "Allow Azure services and resources to access this key vault" in Networking.

As of today, you can only select:
Option 1) ”Allow trusted Microsoft services to bypass this firewall”
Option 2) "IPv4 address"
Option 3) "Virtual networks"

A scenario is, you have a “Azure WebApp”, and Identity is set to off.
Then the WebApp is not a “trusted Microsoft services”, therefore option 1 is not useable.

Option 2, the IP address solution, is not useable when you have many WebApps, and many key vaults, in our case we should then manually handle over 1000 IP address.

Option 3, if you don´t use "Virtual networks", then is should not be necessary to add this, for using key vault, in our case it complicates the azure setup, and we don’t want to use “Virtual networks”.

Therefore, an option 4; “Allow Azure services and resources to access this Key Vault” is needed.
This option is already possible in SQL service for example.

I would like to see the security worldpackage information for the Key Vault in the Kyeey Vault information so that it is easier to deduce the package to us. This must be made available in AzPs, CLI, SDK and via the REST APIs

Get-AzureRmKeyVault -VaultName Bxxxxxxxp

VaultUri : https://bxxxxxxxp.vault.azure.net/
TenantId : 0b98xxxx-xxxx-xxxx-xxxx-xxxxxxxxf102
TenantName : 0b98xxxx-xxxx-xxxx-xxxx-xxxxxxxxf102
Sku : Premium
EnabledForDeployment : False
EnabledForTemplateDeployment : False
EnabledForDiskEncryption : False
EnableSoftDelete :
OriginalVault : Microsoft.Azure.Management.KeyVault.Models.Vault
ResourceId : /subscriptions/2ed3xxxx-xxxx-xxxx-xxxx-xxxxxxxxf1f7/resourceGroups/Bxxxxxxxp/providers/Microsoft.KeyVault/vaults/Bxxxxxxxp
VaultName : Bxxxxxxxp
ResourceGroupName : Bxxxxxxxp
Location : westeurope
Tags : {}
TagsTable :
SecurityWorldRegion : Europe | France | Germany etc.

> Name of the security world package that will wrap BYOK keys for this key vault

If you try to add a vNet/subnet to a Key Vault's firewall, the subscription where that vNet lives must have the Key Vault resource provider registered. If the Key Vault resource provider is not registered in the vNet's subscription, the error you see leads you down a different rabbit hole. Here's an example of the error message:

Virtual Network could not be validated. code: AuthorizationFailed. message: "The client '{guid}' with object id '{same_guid}' does not have authorization to perform action 'microsoft.network/virtualnetworks/taggedTrafficConsumers/validate/action' over scope '/subscriptions/my-vNet-subscription-guid/resourcegroups/my-Resource-Group/providers/microsoft.network/virtualnetworks/my-vNet/taggedTrafficConsumers/Microsoft.KeyVault.centralus' or the scope is invalid. If access was recently granted, please refresh your credentials.".

That error message led us to believe that the problem was permissions-related, but in reality, the fix described in this StackOverflow entry was closer to the mark:

https://stackoverflow.com/questions/54155808/the-client-with-object-id-does-not-have-authorization-to-perform-action-taggedtr

Once we registered the Key Vault resource provider in the vNet's subscription, we were able to add the vNet to the Key Vault's firewall.

This suggestion is to surface the fact that the Key Vault resource provider needs to be registered in the subscription where the vNet lives in order for this integration to work properly.

Thank you for considering this.