One Developer on the firmware team is the only person who understands the low-level driver code, rarely documents anything, and has not paired with or explained the code to any teammate, creating a serious risk if that person is ever unavailable, so what does the Scrum Team's expectation of working together most directly call for here?

Self-managing, cross-functional Developers are expected to work together closely enough that critical knowledge does not depend on any single individual being available, because a team that can only function when one specific person is present is fragile in a way that directly threatens its ability to deliver a usable Increment consistently. Waiting for that Developer to become unavailable before addressing the gap converts a manageable, proactive fix into an urgent crisis at the worst possible moment. Bringing in an external contractor treats the symptom — needing more driver expertise — without addressing the actual problem, which is that the knowledge already inside the team isn't being shared within the team. It is also not primarily the Scrum Master's job to personally absorb and document specialized technical knowledge; the Scrum Master facilitates and coaches, but the Developers themselves are accountable for how the work gets done and for building the collective capability to do it. The healthier pattern is active knowledge-sharing — through pairing, walkthroughs, or documentation created by the team itself — so expertise becomes a team asset rather than a single person's liability. A concrete check is to ask a different Developer to make a small, low-risk change to the driver code without help — if that's not realistically possible today, the knowledge silo is still there.