[ACBRNFe: Exclusão de certificado A3?]

Boa tarde.

Primeira vez interagindo com a comunidade do ACBr.
Quero dizer que estou utilizando o ACBr a algum tempo já.. E que antes utilizava o Monitor feito pelo pessoal da Unimake.
Bom, seguinte.. Estou registrando o mesmo problema relatado pelos colegas.. Em 3 Clientes, que utilizam win7 32 e 64 bits, as chaves privadas do certificado foram apagadas... Todas elas eram certificados da Certsign e pesquisando na internet achei esse tópico.
Primeiramente quero dizer que estive utilizando Unimake com (.net framework para asssinar) de 2008 a 2014 e nenhuma vez tive problema de clientes perderem o certificado.

Não acredito também que seja um problema de código do ACBr, por que conforme relato do colaboradores do projeto.. sempre está em mode de somente leitura.
Store.Open(CAPICOM_CURRENT_USER_STORE, FCertStoreName, CAPICOM_STORE_OPEN_READ_ONLY);

Quero levantar algumas observações e algumas suposições que talvez nem façam sentido.. Mas..

1. O problema pode estar em várias camadas
- No código de minha aplicação.. (Mas não chamo algumas funções especificas para a seleção do certificado, acho que não pode ser isto)
- No código do ACBr.. (mas como já cidado acima, sempre utiliza CAPICOM_STORE_OPEN_READ_ONLY)
- Nas próprias .Dlls do Capicom

2. Concorrência de aplicações
- Pelo que percebi, um certificado A3 fica alocado no componente TACBrNFe na inicialização e uma segunda aplicação que tenta utlizar o
certicado A3 dispara problemas de "canais seguros".
- Se a aplicação for bastante persiste e com acessos simultaneos acredito que existe a possibilidade de se corromper a chave privada..

3. Se parar para pensar.. Os Certifidos A1 também em algum momento já corrompeu.. Mas como temos o backup acabamos por desistalar e instalar novamente..
Então talvez nem seja um problema isolado com A3..

4. ACBrCAPICOM_TLB quando cria o Objeto IStore3.. Utilizar CreateComObject de System.Win.ComObj.pas do delphi.. e consequentemente .dll do Windows, podendo
ser BUG do Delphi mesmo ou do SO.

5. Qualquer aplicação pode utilizar Certificados.. Imagine um software mal intensionado que não tem a senha do A3, mas que utilize as .dll do capicom,
e utilizando um comando para apagar o certificado? (sem senha, iria abrir a caixa de dialogo padrão, o usuário iria digitar manualmente a senha e o certificado já
era).

Penso que existem muitas possibilidades a se considerar para resolver este problema..
Talvez algumas formas de tentar remediá-lo.

Penso que se o programador tem a possibilidade de conseguir excluír uma chave privada de um certificado..
Também deveria ter a possibilidade de se fazer um backup do mesmo..
Talvez extrai-lo para um .PFX e utiliza-lo como A1..

A JwaWinCrypt.pas do ACBrCapicom contém constantes e funcoes de exportação, não sei se é somente para as chaves públicas..
o fato é que estou pensando em sustituir a const "CRYPT_DELETEKEYSET   = $00000010;" para um valor de leitura e compilar uma nova .dll
somente para ter certeza que não é algo do ACBr/Capicom que está ocasionando tudo isso..

sei lá