Teams is not special. The same analysis is, and needs to be, made on any software or SaaS that plays a key role in an organisation.
You ask for evidence, but that's not what you need. There is not, and will never be, some piece of evidence that says, "there is no risk".
You need to take into account:
- the data it processes for your org
- the accounts in your org that need to access it and what access those accounts have access to
So, you need to assess the risks and determine where and how the software is critical for you, then determine mitigations to
- reduce the risk of an adverse event happening
- reduce the risk when an adverse event happens
Then you figure out the benefits of having the software, compared to the costs of mitigations and residual impacts outside of the mitigations, then make the call whether or not the software is "worth the risk".
In other words, you need to perform a risk analysis, not just a vulnerability analysis or a threat modelling exercise.
Taking your post point by point:
Once the tool stopped working, the employees had a day off as no teleconferences (which are a big part of everyday communication) could take place at all.
That's certainly not true for all orgs. Some orgs could function just fine without Teams to hold meetings.
vulnerabilities, 0 days, data leaks, APTs, stuff like that
Setting aside availability, as you said, then you're looking at a constrained set of high-level risks between all of those: unauthorised data access and account compromise. Once you understand the risks, you can then devise mitigations, for instance, by only allowing certain data over Teams (by policy and by technical control).
I tried to look for some threat/risk analysis for Microsoft Teams myself but could not find any.
I googled "threat/risk analysis for Microsoft Teams" and found a lot. But it might not have been what you expected. Teams is a platform that is used in many different ways by different orgs, so there isn't a pre-defined list of specific things to assess. It's more dynamic and complex than that.
Risk Assessment isn't something that someone else can do for you. Risks are not vulnerabilities. Risks are not threats. Although many people speak of those 3 concepts as the same thing. Once you make those concepts more distinct, you can perform a risk assessment that is relevant to your own context, and then you can make informed decisions based on all factors, not just the technically constrained ones.
I help orgs do this assessment all the time. I had a big meeting yesterday with an org that was considering various technical mitigations for the various risks they identified in M365. They had accepted a lot of risk because the value of the software/service was far greater than the risks, but they also wanted options to reduce the risk, too. Risk Management is a constant balance with ever-shifting factors. That's why there is a whole sub-practice in cyber security dedicated to these activities.
