Multifactor authentication in OSH systems

Multifactor authentication combines different factors to protect access. In OSH it helps safeguard sensitive records and functions.

In brief

Multifactor authentication combines different factors to protect access. In OSH it helps safeguard sensitive records and functions.

Contents
  1. What an authentication factor is
  2. Why it matters in prevention
  3. Not all methods are equivalent
  4. Enrolment and recovery also need protection
  5. Implementation example
  6. What must be verified
  7. Related concepts
  8. References

A–Z dictionary →

What an authentication factor is

Multifactor authentication, or MFA, requires verification of more than one type of factor: something known, something possessed or a characteristic inherent to the person. Two passwords are not two different factors. Verification may be integrated into a single authenticator or combine several, depending on the design and the system’s required assurance level.

Why it matters in prevention

A compromised account can expose health data, alter an assessment or enable contractor documentation to be downloaded. MFA reduces dependence on passwords but should be accompanied by proportionate permissions and protection of health information. It does not prevent a correctly authenticated person from abusing excessively broad authorisations.

Not all methods are equivalent

Manually entered codes can be captured through deception. Phishing-resistant authenticators bind the operation to the legitimate service using cryptographic mechanisms. Selection requires consideration of risks, available devices and accessibility. An unexpected approval request should not be accepted just to make it disappear: it may indicate someone else’s access attempt.

Enrolment and recovery also need protection

Registering a new authenticator or recovering an account are sensitive operations. If a weak procedure is enough to replace the second factor, the effectiveness of the whole system is reduced. The organisation defines how it verifies identity, removes lost devices and communicates changes. Recovery codes are protected and are not shared through messaging or with people claiming to act as support.

Implementation example

In a hypothetical example, a preventive service enables MFA for administrative and healthcare accounts. Before wider rollout, it checks routine access, phone changes, device loss and use from authorised computers. Testing includes personnel with accessibility needs. The result should maintain protection without creating operational dependence that prevents urgent situations from being addressed.

What must be verified

Which accounts are covered, which methods are allowed and how exceptions are reviewed should be confirmed. The mere existence of an MFA option in a product does not demonstrate that it is applied. Monitoring should consider sessions, alerts, service accounts and recovery mechanisms, with clear responsibilities between the organisation and provider.

References

  1. NIST: Digital Identity Guidelines. Official source
  2. NIST SP 800-63B-4: authentication and authenticator management. Official source

Editorial information

Publication date: 1 November 2026.

Editorial responsibility: Sabentis Editorial Team.

Author: Pablo RodríguezLinkedIn

Executive Vice President of the ORP International Foundation and Chief Financial Officer of Sabentis.

Request a Demo

Discover all that Sabentis can do for your organization.

Try Sabentis

request a demo
stars 5
GetApp Software Advice Capterra