我认为您的安全供应商远非透明这一事实已经是一个非常糟糕的情况。
当供应商对安全细节保密时——无论是事件的细节，还是产品本身的安全内部（或至少是安全证明，例如加密算法）——这对整个安全态势都是一种固有风险。你自己的组织。

现在，虽然在某些情况下接受风险是合法的，但不应轻易接受这样的风险（让您的整个安全架构依赖于第三方，这可能是也可能是不可信的）。
当供应商开始倾向于隐瞒关键信息，而不是支持客户做出明智的选择时，我会说风险接受决策开始有点模糊。

因此，如果我处于那个位置（并且忽略预算、时间和政治等限制），我会重新评估我与所有供应商的关系，这些供应商提供了我基础设施的关键部分。请注意，这与实际影响无关——高影响缺陷可能发生在（几乎）任何人身上——重要的是你选择如何处理它。
在我看来，在这种情况下，他们处理（或不处理）的方式表明他们不了解需要建立的信任关系，才能使上述风险接受有效。至少，我可能会考虑通过带有惩罚条款的严格 SLA 将供应商关系更改为风险转移而不是接受。

在这种特定情况下？
好吧，假设在这笔交易得到排序之前切换整个身份验证机制是不​​可能的——除了激活更多登录登录、特别注意异常登录、观察你的用户所做的事情，并通常尝试尽量减少用户的访问...

如果供应商在您使用的系统上遭受损害，并且拒绝向您提供有关该损害对您的系统的影响的令人满意的详细信息，那么您应该寻找的是……一个新的供应商。

最坏的情况是安全系统的用途完全崩溃。例如，在身份验证系统中，攻击者知道的足够多，可以使用他们希望使用的任何虚假身份来验证自己，并且还可能阻止有效用户进行身份验证，或者破坏他们的身份验证过程，以便服务器使用错误的 ID 透明地对他们进行身份验证。

这个问题真的回到了风险管理，我什至不是在谈论源自信息安全管理的风险管理。

我说的是项目管理风险管​​理。很多公司都有 PMO（项目管理办公室），但很少有公司拥有项目风险专家。

在确定项目范围时，例如将身份管理外包给供应商的产品（例如 RSA SecurID）——项目风险经理会说，“我们应该在这个单一供应商解决方案中投入多少？” ——不是从安全的角度，而只是从“经营业务”的角度。

在我看来，当一家大公司购买产品并将其推出时（这也适用于外包和云计算，包括 SaaS），你的想法是不要把所有的鸡蛋放在一个篮子里。如果您的主要供应商离开 - 转移到二级或三级供应商有多容易？

计划时——很容易将供应商/供应商分成百分比和超额填充。如果您有一个 100% 的内部解决方案，请考虑添加一个外部解决方案来填补 20% 的空白。然后，再增加 20% 的供应商——40% 的外部解决方案。在进行一些绩效会计（可能还有财务会计）分析以及您自己的内部审计绩效和围绕所述产品的业务指标之后，确定哪一个提供商是最值得的。

如果一个解决方案很突出——再增加 20%，并且如果它们在另一个时间段（6 sigma 的循环或迭代）内表现良好，则添加最后的 20%。然后你有两个供应商——一个在 20%，一个在 60%（还有 20% 仍然在内部）。作为最后一步，以 20% 的价格添加第三个供应商/供应商解决方案（对于完全外包的解决方案）。但是，如果需要，请保留在特定时间段内回退到 20% 解决方案的能力。看看他们的表现如何。使用您的第二个和第三个提供商——看看他们中的任何一个是否可以在试运行期间再承担 20%（就像您的第一个提供商所做的那样）。如果他们通过了，请执行失败场景，将主要供应商降低到 40%，让二级或三级供应商在一段时间内承担额外的 20%。

从长远来看——您将能够快速从一个解决方案点转移到另一个解决方案点——甚至可能回到内部解决方案。这不仅仅是信息安全管理、风险管理或灾难恢复/业务流程操作。这是很好的项目管理实践！

我敢肯定，其他人会有更好的答案，但我认为在最坏的情况下，它需要立即撤销所有令牌，并对用于保护令牌的所有系统进行审计。

我认为最坏的情况应该由业务定义，每个业务。