Severity: Info
File: src/Servy.Core/Security/ProtectedKeyProvider.cs lines 212–218

Description:
During key decryption the provider tries machine-entropy DPAPI first, falls back to legacy null-entropy DPAPI (v7.8 compat) on CryptographicException, and then attempts to auto-migrate the on-disk file by re-saving with the new entropy. If that save fails, the exception is logged at Warn and the decrypted data is returned so the service stays up:

catch (Exception ex)
{
    // Trip the warning so admins can diagnose I/O or permission issues.
    // We still return the data so the service remains operational.
    Logger.Warn($"Key migration to entropy-protected format failed for '{path}': {ex.Message}");
    return decryptedData;
}

The operational impact is subtle: subsequent reads will hit the v7.8 fallback again and retry the migration, but the admin only sees a single Warn line per attempt. A one-shot transient IO error is indistinguishable from a persistent ACL or disk-space problem that leaves the key permanently in the weaker protection.

Suggested fix:

• Keep the return decryptedData behaviour for uptime, but escalate signal on repeat failure. A static counter per path (or an EventLog entry when a threshold of consecutive migration failures is crossed) makes the stuck state obvious.
• Alternatively/additionally, expose a small health surface (startup banner, dedicated log line on service start, or an admin CLI servy security status) that reports "N protected keys are still in legacy DPAPI format" so operators have a positive signal rather than "no news".
• Tag the Warn with a stable event id / marker so log queries can alert on it directly.