I applied bold typeface to the part of the following quote that aligns with my experience.
As
@Kuldeep Singh pointed out, the standard does allow the safety class to be lowered if measures external to the software are taken.
In practice, I've found this mostly indefensible. It seems like pretty much everyone requires the software to be a safety class comparable to the device class. I have successfully argued that some software applications in a device with multiple software components can be lower but something had to be assigned a comparable safety class. Curious if others have had different experiences.
I have had experience with well-defined software architectures that made it perfectly clear that certain elements of the software merited a lower software system safety classification, but even in those instances the teams defaulted to the higher 'base' classification! The team in question simply didn't want to appear to have done incomplete work.
I have had this experience (with a certification agency) that isn't directly related to software, but came as a rude awakening vis-a-vis external bodies that politely express 'skepticism' but don't shy from using vernacular terms like 'weaseling'. I was involved with a legacy design that was not completely re-engineered/refactored, but was put through a thorough, modern, and complete design control process. One element of this re-examination was a revisit of the user interface (informed by modern usability standards and expectations) that included protocols using external, independent users which solicited feedback about the user experience with the device. Among the outcomes of the user testing was a clear preference for one specific element of the design that ran counter to a single requirement of a collateral standard; additionally this particular user preference had been long examined in the literature and as far as the current 'state of the art' is concerned is a settled question, because the alternate (mandatory, per the collateral standard) introduces unacceptable risks and reduces the effectiveness of implemented (classical, familiar) risk controls.
Naturally we expected this to be a potential point of contention, so we made sure that our risk file was complete with all the necessary objective evidence to support an exception to the collateral standard by using of 4.5 of 60601-1, only for this one specific requirement of the collateral standard. Our certification body rejected our efforts, as near as I can tell,
pro forma. The CB literally kept pointing at the one element of the collateral standard despite us acknowledging that we intended to not meet it because to do so would introduce higher levels of risk. We eventually got the certification without having to make a design change which would negatively impact the risk profile for the device, nor did we have to generate any new objective evidence, but it was a protracted process that was indistinguishable from teaching the folks at the CB how we used a 14971-compliant risk management process to support all elements of medical device design, including 60601-1.