Legacy ASPNET_REGIIS encryption suddenly broken?

We have encountered a very concerning problem regarding web.config encryption in our legacy ASP.NET web environment.

1. Situation

For several years, our web deployment process has involved using TFS (AzureDevOps) to compile our code, merge our web.config files, then invoke aspnet_regiis to encrypt credentials stored therein - all using a common key deployed to all of our servers. This process has worked flawlessly for years - until apparently about two days ago.

2. Problem

Approximately two days ago, we suddenly started seeing app failures traced back to a "Failure to decode OAEP padding" error at runtime on a recently deployed app. Any newly deployed application or web.config file encrypted via aspnet_regiis now will not decrypt on any other server despite specifying the identical key on each target machine.

3. What we've tried

• Research on this error in other articles noted this was often due to improper use of public/private keys during encryption. As this process was automated, and has been working literally for years , we dismissed this as a possibility.
• I manually re-created the key container and re-imported the key from the original exported XML source
• I verified that the encryption provider targets the common key container deployed to all environments, and that the provider uses the machine key storage.
• I verified all relevant permissions were present on the key container.
• I verified via ProcMon that correct machine key is, in fact, being used.
• I created a "sample" web.config, copied it to three different machines with the same common key deployed, and performed encryption on a "phony" connectionStrings section. The "CipherValue" in each case differed, and none of those encrypted files could be decrypted on any other server.

My theories center around the notion that something in the behavior of aspnet_regiis has changed

• The cipher and/or hash algorithms differ between systems
• The RSA provider, despite being told to use a specific key container, is somehow using a machine-specific private key that necessarily differs between servers.

Environment: Windows Server 2016 version 1607 w/IIS 10.0 (server) Windows 10 build 22H2 (desktop)

I am looking for any way to restore the behavior wherein a common key deployed to all environments allows for common encryption/decryption, as has been the case for the last several years. I have researched breaking changes to aspnet_regiis and have found nothing.

After nearly two days of research, we were able to track down the problem described above to a corrupted machine key. We do not know how the key became corrupted, but restoring it has solved the issue.

We have turned on file-level auditing on the key file to help identify the source of any subsequent changes.