Currently, FUJIFILM's internal system uses a Public server certificates, but in the future, we will consider whether there is something that can be replaced by issuing a Private server certificates, so that if any similar incident occurs in the future, we will take effective measures to deal with it promptly
Th9is is not really a step towards resolving the situation or ensuring it won't be repeated. This is a "Well, we'll look into things, and hope it doesn't happen again".
The fundamental issue here is that SECOM sold unauthorized, invalid, non-compliant certificates to FUJIFILM, and seemingly does not want to take responsibility for addressing the issue they created. The explanation provided here is no different than the explanations provided by past CAs, including SECOM, and that's a problem: SECOM has failed to take appropriate steps to learn from these past incidents and take steps to prevent this from happening in the future, which is how we got to where we are now.
The proportionate response to a revocation delay is dependent upon how well the CA, in this case, SECOM, demonstrates both that it has learned from past incidents and taken reasonable steps to prevent the same thing from happening for their own CA and customers, and that this situation is meaningfully new or different from these past situations. Yet that's clearly not the case here.
This puts root programs in an awkward place: SECOM has agreed to abide by the same rules all CAs are expected to, but is now declaring it won't, and for reasons that it reasonably could have known of and taken steps to prevent, but did not. This does not paint a picture of a CA actively prepared to deal with or is dealing with things.
This may seem a particularly harsh response for what, in effect, boils down to a 5 day delay, but the point is that SECOM can and should have been working to prevent any delays, so that it could meet the longstanding (nearly decade-long) requirements. On 2020-07-26, SECOM posted this comment, https://bugzilla.mozilla.org/show_bug.cgi?id=1649962#c10 , which acknowledged a lack of automation was a significant contributor to delays, which was further expanded upon on 2020-08-07 in https://bugzilla.mozilla.org/show_bug.cgi?id=1652610#c4 , and yet here we are, 9 months later, dealing with seemingly the same root issue.
SECOM needs to have a plan to address this, and also needs to have a plan for how it will remain accountable for the requirements it agreed to. For example, if SECOM hasn't prioritized automation since that discussion, that's entirely relevant and germane to this discussion. If SECOM supports automation, but FUJIFILM declined to adopt it, then it seems clear that any outage is, fundamentally, caused by FUJIFILM, and revocation would be entirely consistent with the Subscriber Agreement.
I realize all the certificates have now been revoked, as of 2020-04-26, and while it's good that there was only a 5 day delay, it's quite bad, especially given the context, that there was any delay at all. Unless and until SECOM has the tools in place to ensure it complies with industry requirements, it seems like this should be a top-level priority of SECOM to the exclusion of all other development. If that's not the case, SECOM should be candid and transparent about what's "more important" than this compliance (e.g. perhaps there are other areas of non-compliance being addressed first), and be clear about it's timeline to getting a point where, from both a technical implementation and a business policy, they're able to comply with the BRs and Root Program Requirements.