Merge pull request #96562 from MladjoA/patch-5

Expiration date is now allowed for key

Author: PRMerger6

articles/sql-database/transparent-data-encryption-byok-azure-sql.md

@@ -10,13 +10,13 @@ ms.topic: conceptual
 author: aliceku
 ms.author: aliceku
 ms.reviewer: vanto
-ms.date: 11/04/2019
+ms.date: 11/19/2019
 ---
 # Azure SQL Transparent Data Encryption with customer-managed key
 
 Azure SQL [Transparent Data Encryption (TDE)](https://docs.microsoft.com/sql/relational-databases/security/encryption/transparent-data-encryption) with customer-managed key enables Bring Your Own Key (BYOK) scenario for data protection at rest, and allows organizations to implement separation of duties in the management of keys and data. With customer-managed transparent data encryption, customer is responsible for and in a full control of a key lifecycle management (key creation, upload, rotation, deletion), key usage permissions, and auditing of operations on keys.
 
-In this scenario, the key used for encryption of the Database Encryption Key (DEK), called TDE protector, is a customer-managed asymmetric key stored in a customer-owned and customer-managed [Azure Key Vault (AKV)](https://docs.microsoft.com/azure/key-vault/key-vault-secure-your-key-vault), a cloud-based external key management system. Key Vault is highly available and scalable secure storage for RSA cryptographic keys, backed by FIPS 140-2 Level 2 validated hardware security modules (HSMs). It doesn't allow direct access to a stored key, but provides services of encryption/decryption using the key to the authorized entities. The key can be generated by the key vault, imported, or [transferred to the key vault from an on-prem HSM device](https://docs.microsoft.com/azure/key-vault/key-vault-hsm-protected-keys).
+In this scenario, the key used for encryption of the Database Encryption Key (DEK), called TDE protector, is a customer-managed asymmetric key stored in a customer-owned and customer-managed [Azure Key Vault (AKV)](https://docs.microsoft.com/azure/key-vault/key-vault-secure-your-key-vault), a cloud-based external key management system. Key Vault is highly available and scalable secure storage for RSA cryptographic keys, optionally backed by FIPS 140-2 Level 2 validated hardware security modules (HSMs). It doesn't allow direct access to a stored key, but provides services of encryption/decryption using the key to the authorized entities. The key can be generated by the key vault, imported, or [transferred to the key vault from an on-prem HSM device](https://docs.microsoft.com/azure/key-vault/key-vault-hsm-protected-keys).
 
 For Azure SQL Database and Azure SQL Data Warehouse, the TDE protector is set at the logical server level and is inherited by all encrypted databases associated with that server. For Azure SQL Managed Instance, the TDE protector is set at the instance level and is inherited by all encrypted databases on that instance. The term *server* refers both to SQL Database logical server and managed instance throughout this document, unless stated differently. 
 
@@ -76,9 +76,9 @@ Auditors can use Azure Monitor to review key vault AuditEvent logs, if logging i
 
 - TDE protector can be only asymmetric, RSA 2048 or RSA HSM 2048 key.
 
-- The key cannot have activation or expiration date set.
+- The key activation date (if set) must be a date and time in the past. Expiration date (if set) must be a future date and time.
 
-- The key must be in the Enabled state in the key vault.
+- The key must be in the *Enabled* state.
 
 - If you are importing existing key into the key vault, make sure to provide it in the supported file formats (.pfx, .byok, or .backup).