PKCS#12 Restoration: Reject Legacy Ciphers or Restore and Re-Encrypt

OpenSSL 3.x offers the pkcs12 command for exporting and importing certificates and private keys into a single encrypted archive. During restoration, the command performs MAC verification to confirm the archive has not been tampered with, but it does not verify the key's usability or enforce a minimum encryption strength, accepting whatever algorithm was used during export. Some archives in deployment were created years ago with legacy encryption algorithms such as DES or 3DES, which remain supported for backward compatibility but are discouraged due to weak security. This presents a policy decision for restoration pipelines: whether to reject any archive encrypted with legacy ciphers outright and force re-export from the source system, or to restore them as-is and immediately re-encrypt with stronger algorithms, accepting a temporary window where key material is handled under weak protection. Furthermore, MAC verification confirms archive integrity but does not confirm that the recovered key actually matches its certificate or is functionally usable until additional validation is run. Given these dynamics, what trade-off is safer in practice: hard-failing on legacy ciphers during restore, or restoring and then re-encrypting? Is there a documented way to enforce a minimum cipher or MAC algorithm during the pkcs12 import path, or must this validation be handled externally? And what approach is recommended to confirm the restored key pair corresponds to its associated certificate before the archive is trusted?