Detent PointAlways Encrypted stacks two keys. The column encryption key wraps the column data and lives, encrypted, in the database. The column master key wraps the column encryption key and lives in a key store — a certificate store or a vault — not in the database at all. The database keeps a pointer: a provider name and a key path.
That design is the security property: the engine never sees the master key, so a compromised server still can’t read the columns. It is also the operational catch — the pointer can outlive the certificate it points to, and nothing in the database notices until a client fails to decrypt.
Registering a column master key writes that pointer — the provider and key path for a certificate you already hold — into the database’s metadata. register_sql_column_master_key does exactly that step and no more; it is a paid, licensed tool (Starter tier and up).
It is deliberately scoped to the metadata. Creating the column encryption keys and encrypting the columns themselves is cryptography that belongs to the SqlServer PowerShell module, and SqlCertForge leaves it there rather than reimplementing it.
test_sql_column_master_key reads the registered master keys for a database — provider, key path, and how many column encryption keys depend on each one — and, for a certificate-store key, looks up whether that certificate is actually present on this machine. A high dependent-key count on a certificate that has quietly gone missing is the warning you want before an application hits it. The check is read-only and free.