Single Sign-On and Part 11 Signature Requirements: Getting Both

What Part 11 Actually Says About Signature Components

Start with the text, because almost every argument in this area comes from a paraphrase of a paraphrase. Five sections matter, and they do different jobs.

11.200(a)(1): two distinct identification components

The requirement reads: electronic signatures that are not based upon biometrics shall employ at least two distinct identification components such as an identification code and password.¹ Two things in that sentence get missed. First, the words are such as. A user ID and a password are the illustration, not the mandate. Any two distinct components can qualify, provided the rest of subpart C holds. Second, the two-component rule is 11.200(a)(1) itself. The clauses labeled (i) and (ii) do not create the two-component requirement; they govern when you have to execute both of them.

That distinction matters because a common shorthand (“11.200(a)(1)(i) requires two components”) leads people to argue about the wrong clause. The two components are always required for the signature to exist. The session rule only changes how many of them you execute at each individual signing.

11.200(a)(1)(i) and (ii): the session rule

Paragraph (i): when an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual.¹

Paragraph (ii): when an individual executes one or more signings not performed during a single, continuous period of controlled system access, each signing shall be executed using all of the electronic signature components.¹

Read the qualifier in paragraph (i) carefully. The component reused on subsequent signings has to be one that is only executable by, and designed to be used only by, the individual. A user ID printed on a badge does not meet that test. A password, a PIN held only by the signer, or a biometric does. This is why the shortcut of “we already know who they are, so a confirm button is enough” fails: a confirm button is not a signature component that only the individual can execute.

11.200(a)(2), (a)(3) and (b): ownership, collaboration, biometrics

Signatures must be used only by their genuine owners, and must be administered and executed so that attempted use by anyone other than the genuine owner requires collaboration of two or more individuals.¹ The collaboration clause is the reason a purely possession-based method is difficult on its own: FDA explained in 1997 that it was thinking about a card or token a person might leave unattended, and that requiring disclosure of a password raises the risk of betrayal and therefore deters the behavior.⁷ Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by anyone other than their genuine owners.¹

11.100: uniqueness, identity verification, and the certification letter

Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else. Before an organization establishes, assigns, certifies or otherwise sanctions an individual’s electronic signature, or any element of such electronic signature, the organization shall verify the identity of the individual.²

Note the phrase or any element of such electronic signature. In a federated design, the identity provider assigns the element. If provisioning into the identity provider happens through an automated feed from a human resources system, the identity verification obligation follows the element back to whoever performed it, and that step needs a record.

11.100(c) requires persons using electronic signatures to certify to the agency that the signatures are intended to be the legally binding equivalent of traditional handwritten signatures. This is the non-repudiation letter. It is worth knowing that the only amendment to Part 11 substantive requirements since 1997 landed here (the scope exclusions in 11.1 have been amended repeatedly since): on March 2, 2023, a technical amendment replaced the fixed mailing address in 11.100(c)(1) with wording that allows submission in electronic or paper form and points to FDA’s web page for the current destination.¹²¹³ No obligation changed. Companies that still hold a decades-old letter and have since changed corporate name or legal entity should check whether their certification still matches the entity that operates the systems.

11.10(d) and 11.50: access limits and manifestation

11.10(d) requires limiting system access to authorized individuals.⁶ It is one line, and it carries most of the weight in an SSO discussion, because in a federated design the authorization decision has moved into the identity provider and the group memberships that drive it.

11.50 requires that signed electronic records contain information associated with the signing that clearly indicates the printed name of the signer, the date and time when the signature was executed, and the meaning associated with the signature, such as review, approval, responsibility or authorship. Those three items are subject to the same controls as electronic records and must be included in any human readable form of the record, on screen or in print.³ 11.70 requires that signatures be linked to their records so they cannot be excised, copied or otherwise transferred to falsify a record by ordinary means.⁴

11.300 then adds the controls around identification codes and passwords: uniqueness of each combined code and password, periodic checking or recall or revision, loss management for tokens and cards, transaction safeguards that detect and report attempted unauthorized use in an immediate and urgent manner, and initial and periodic testing of devices that bear or generate credential information.⁵

The Session Rule, and Who Gets to Define a Session

The phrase “single, continuous period of controlled system access” appears twice in the regulation and is defined nowhere in it. FDA addressed it directly in the preamble to the 1997 final rule, and that discussion is the closest thing to an authoritative reading that exists.

What FDA said in 1997

FDA distinguished between signatures executed repetitively during “a single, continuous controlled period of time (access session or logged-on period)” and those that are not.⁷ That parenthetical is the definition most people are looking for. A continuous period of controlled system access is an access session, a logged-on period.

The agency then described the model it had in mind. An individual performs an initial system access or log on, “which is effectively the first signing,” by executing all components of the electronic signature, typically both an identification code and a password. The individual then performs subsequent signings by executing at least one component, under controlled conditions that prevent another person from impersonating the legitimate signer.⁷

FDA named the concern plainly: if the person leaves the workstation, someone else could access it and impersonate the legitimate signer. It then listed the controls it considers vital in that situation:

FDA also set out four procedures it expects when non-biometric signatures are executed more than once during a single, continuous controlled session: all components executed for the first signing; at least one component executed at each subsequent signing; the component used after the first signing usable only by its genuine owner and designed so it can only be used by its genuine owner; and administration that requires collaboration of two or more individuals for anyone else to attempt use.⁷

Who decides where the boundary falls

You do. FDA has published no maximum session duration, no required inactivity threshold and no test for continuity. It described conditions, not a clock. That is a deliberate design: the same regulation governs a chromatography data system in a laboratory, a document management system on a desk, and a batch execution terminal in a filling suite, and no single timer is right for all three.

What that means in practice is that the definition of a continuous period is a documented company decision, made per system or per system class, justified by the physical and procedural controls that surround it. Two failure modes show up in reviews.

The first is defining the session too broadly. A federated session that lasts a working day, survives the laptop lid closing, and follows the user between buildings cannot honestly satisfy a condition that begins with “remain in close proximity to the workstation.” A company that reuses that session as the first signing has adopted the benefit of paragraph (i) without the conditions FDA attached to it.

The second is defining the session too narrowly without thinking about behavior. If a reviewer approving forty deviation records has to retype a full credential set forty times, credential sharing and workarounds appear. That is not a theoretical risk. A recurring data integrity finding in this space is people using one another’s credentials to get through volume.

What FDA Has Said Since 1997, and What It Has Not

The 2003 Scope and Application guidance

The 2003 guidance is the document everyone reaches for, and it is routinely misread as a general softening of Part 11. It is not. FDA said it would interpret the scope narrowly and would exercise enforcement discretion over specific requirements: validation, audit trails, record retention and record copying, plus a broader discretion for legacy systems that were operational before August 20, 1997.⁸⁹

It then listed what it still intends to enforce. The list includes limiting system access to authorized individuals, operational system checks, authority checks, device checks, personnel qualification, written policies holding individuals accountable for actions initiated under their electronic signatures, controls over systems documentation, corresponding controls for open systems, and “requirements related to electronic signatures (e.g., §§ 11.50, 11.70, 11.100, 11.200, and 11.300).”⁸

The clinical investigations guidance, and a date correction

There is a widely cited FDA question and answer guidance on electronic systems, electronic records and electronic signatures in clinical investigations. It is frequently referred to as the 2023 guidance. That is the draft. The draft was issued in March 2023. The final guidance, revision 1, is dated October 2024, and the Federal Register notice of availability published on October 2, 2024.¹⁰¹¹ If you are citing it in a validation rationale or an inspection response, cite the final October 2024 version.

Scope matters as much as the date. The guidance covers clinical investigations of medical products, foods, tobacco products and new animal drugs, and is addressed to sponsors, contract research organizations, clinical investigators and institutional review boards. It states that it expands on recommendations in the 2003 guidance that pertain to clinical investigations conducted under 21 CFR parts 312 and 812.¹⁰ Clinical scope is not manufacturing scope. A GMP quality organization can read it as evidence of FDA’s current thinking on the same regulation, and that is genuinely useful, but it cannot be cited as the authority for a manufacturing execution system configuration. If your validation rationale for a shop-floor terminal rests on a clinical guidance, an inspector is entitled to ask why.

With that boundary stated, what the guidance says is helpful. It restates 11.200(a)(1)(i) in plain terms. It confirms that Part 11 does not specify a particular method to create a valid electronic signature and gives examples including computer-readable identification cards, biometrics, digital signatures, and username and password combinations. It says Part 11 requirements do not specify any particular methods for implementing access controls, and that access controls may include multifactor authentication, strong login credentials and biometrics. On identity verification under 11.100(b), it says methods may include official government-issued identification, security questions, or strong digital login credentials accompanied by multi-factor authentication or video observation. It states that signatures drawn with a finger or an electronic stylus are handwritten signatures rather than electronic signatures. And it confirms that FDA does not certify electronic systems or the methods used to obtain electronic signatures.¹⁰

What FDA has not said

FDA has issued no guidance that addresses single sign-on by name, and none that addresses federation protocols, session tokens or step-up authentication. There is no agency position that blesses or forbids a particular SSO configuration. Anyone who tells you otherwise is describing an interpretation, and an interpretation is exactly what you are responsible for producing and defending.

Where SSO, Federation and MFA Meet the Signature Rule

Four things that get conflated

Most of the disagreement between a security team and a quality team comes from using one word for four different events. Separate them and the design becomes straightforward.

What federation actually hands the application

In a SAML or OpenID Connect design, the application no longer verifies credentials. It receives an assertion or a token from the identity provider and trusts it. Two claims in that assertion are the technical hooks for a Part 11 conversation.

When the authentication happened. SAML carries a required AuthnInstant attribute on the authentication statement, specifying the time at which the authentication took place.¹⁶ OpenID Connect carries an auth_time claim, defined as the time when the end-user authentication occurred, and that claim is required when a max_age request is made or auth_time is requested as an essential claim.¹⁵ This is what turns “the user has a session” into “the user authenticated at 09:14:02 UTC,” which is a fact you can compare against a signing timestamp.

How the authentication happened. SAML carries an authentication context class reference, and the application can demand one through RequestedAuthnContext. OpenID Connect carries an acr claim identifying the authentication context class the authentication satisfied, and lets the application request specific values through acr_values.¹⁵¹⁶ This is what turns “the user is authenticated” into “the user authenticated with a phishing-resistant method that only they can execute.”

Both protocols also give the application a way to force a fresh authentication rather than accept a session. SAML defines ForceAuthn: if true, the identity provider must authenticate the presenter directly rather than rely on a previous security context.¹⁶ OpenID Connect defines max_age, which specifies the allowable elapsed time in seconds since the end-user was actively authenticated, and prompt=login, which asks the authorization server to prompt the end-user for reauthentication.¹⁵

MFA is a different axis

Multi-factor authentication at the front door answers a security threat model: credential theft, phishing, password reuse. It is a good thing and it should be there. It does not by itself satisfy 11.200(a)(1), because the signature rule is not about how strong the login was. It is about what the individual executed at the moment of signing, and whether that component is one only they can execute.

A useful way to hold both ideas: strong authentication reduces the chance that the wrong person is holding the session. The signature rule assumes that reduction is imperfect and requires a deliberate act anyway. The two controls are additive, not substitutes.

Passwordless and biometric methods

Passwordless authentication built on WebAuthn uses a device-bound credential, typically combined with a local user verification step such as a PIN or a fingerprint. The relying party receives a signed assertion with a flag indicating that user verification was performed; the biometric template is not revealed to the relying party, though for platform authenticators it may be visible to the client depending on the implementation.¹⁷

Under Part 11 that raises a real classification question, and the honest answer is that you have to pick a lane and document it.

• Treat it as non-biometric under 11.200(a). The two components are possession of the device-bound private key and knowledge of the PIN, or possession plus the locally verified inherence factor. You then have to show that both are distinct, that the one reused inside a session is executable only by the individual, and that attempted use by another person requires collaboration of two or more individuals. The weak point is a device left unlocked and unattended, which is precisely the scenario 11.200(a)(3) was written about.⁷
• Treat it as biometric under 11.200(b). Then the design has to ensure the signature cannot be used by anyone other than its genuine owner. Since the relying party sees only a boolean from the authenticator, the assurance depends on the authenticator’s own enrollment and matching behavior, and on the fact that a device PIN can be shared. That is a harder argument to make without vendor attestation evidence.

The pragmatic route many pharmaceutical companies take: use passwordless SSO for access, because it genuinely improves security and reduces password handling, and keep a separate, deliberately executed credential for signing. That sidesteps the classification argument entirely, and it keeps the signing act visible to the user, which is worth something on its own.

An external reference point on session length

Part 11 sets no timer, but you still have to pick numbers, and it helps to align with a recognized standard rather than invent one. NIST SP 800-63B recommends that at authentication assurance level 2 the overall session timeout should be no more than 24 hours and the inactivity timeout no more than 1 hour, and at level 3 states that the overall reauthentication timeout shall be no more than 12 hours, with an inactivity timeout that should be no more than 15 minutes.¹⁴ These are security recommendations rather than Part 11 requirements, and they are not a substitute for a documented rationale. They are useful because they let a quality organization test a proposed number against an external benchmark instead of against an opinion, and because the 15 minute figure is a defensible reading of FDA’s phrase “a fixed short timeframe.”

The Configuration Questions, With Answers

These are the questions that come up in every design review. Short answers first, then the reasoning that matters.

Can an SSO session supply the first component?

Technically it can, and the 1997 preamble supports the idea directly: the initial log on “is effectively the first signing” when all components of the electronic signature are executed at that log on.⁷ But look at what has to be true. The credentials executed at the log on have to be the signature components, not merely a login. The user has to remain in close proximity to the workstation throughout the signing session. An automatic inactivity disconnect has to de-log the user within a fixed short timeframe. And the component executed at each subsequent signing has to be exclusive to the individual.

A federated session designed for productivity is designed to violate the second and third conditions on purpose. It is meant to survive a walk between buildings, a lid closing, a device switch. That is the point of it. Building a compliance argument on top of a mechanism engineered for the opposite goal is a fragile position, and it becomes untenable the moment the identity team extends the session lifetime for a legitimate operational reason.

The practical recommendation: treat the SSO session as access control under 11.10(d), and treat signing as a separate authenticated act. You give up nothing except a small number of keystrokes, and you gain a control boundary that does not move when the identity platform is tuned.

Session timeout and automatic lock

These are different mechanisms with different owners, and conflating them causes real findings. A workstation lock is an operating system control. It protects the screen. It does not necessarily end the application session, and on many platforms unlocking uses a shorter credential than logging on. A federated session lifetime is an identity provider setting. An application session is a third timer, often shorter, sometimes longer, occasionally ignored by a client that refreshes tokens in the background.

For a system where you rely on 11.200(a)(1)(i), all three timers have to be specified, and the shortest one has to be the one that actually ends the continuous period. Test it. Write a test case where the user authenticates, signs once, walks away for longer than the inactivity threshold, returns, and attempts a second signing. The expected result is a full component set, not one component. If the system delivers the reduced path, the session boundary is not where your documentation says it is.

What re-authentication should require

Re-authentication at signing should be a credential act, not an acknowledgment. Specifically:

• An exclusive component. A password, a PIN, or a verified biometric. Not a user name, not a badge tap alone, not a confirmation checkbox.
• Verified fresh, not from cache. If the application delegates to the identity provider, request a fresh authentication using ForceAuthn or max_age with a low value, and validate the returned AuthnInstant or auth_time against the signing timestamp. If the application verifies locally, verify against the credential store at that moment.
• With a known method. Constrain the acceptable authentication context so a user cannot satisfy a signing prompt through a weaker method than the one you qualified. Store which method was used.
• Bound to the record. The result of that authentication must be tied to the specific record and meaning being signed, not to a general “recently authenticated” state that any subsequent action can consume.

That last point is the one that gets missed in implementation. A step-up flow that sets a global “elevated for 10 minutes” flag lets a user authenticate once and sign six unrelated records. Whether that is acceptable depends entirely on whether those six signings are a series inside one continuous period, which brings you back to your documented session definition. Decide it deliberately rather than inheriting it from a framework default.

Where the European direction is going

If you operate in the European Union, one more consideration belongs in the design now rather than later. The European Commission opened a stakeholder consultation in July 2025 on revisions to EudraLex Volume 4 Chapter 4, Annex 11 and a new Annex 22.¹⁸ The draft Annex 11 is a draft. There is no final text and no implementation date, and nothing in it is currently binding. It should not appear in a compliance obligation register as a requirement.

It is still worth reading, because the draft’s clause on electronic signatures takes a firmer line than Part 11 does. It states that when executing an electronic signature a system should enforce a full re-authentication providing at least the same level of security as during system login, that subsequent signatures executed in immediate sequence may use a password or biometrics only, and that relying on the previous system authentication is not acceptable.¹⁸ The draft also proposes an automatic inactivity logout that users cannot change or deactivate, with re-authentication required afterward.¹⁸

Read alongside the Part 11 session rule, the design implication is clear enough to act on: a configuration that never reuses the access session to supply a signature component satisfies the current US rule and would also satisfy the direction the EU draft is pointing. A configuration that leans on the session satisfies Part 11 under conditions and would need rework if that draft language survives. Given that the difference is a prompt, this is an easy call for anyone building a system with a ten-year life.

Shared Workstations and the Shop Floor

The hardest environment is not the office. It is a gowned suite with three terminals, twelve operators, gloves, and a batch record that needs verification signatures at defined steps. A separate article in this series covers the batch record fields that drive investigations, and another covers requirements teams forget when specifying handheld devices in a warehouse. The point here is narrower: how identity works when the device is shared and the signature is not.

The rule that does not bend

The device can be shared. The credential cannot. FDA’s warning letters are consistent on this. In one letter to an active pharmaceutical ingredient manufacturer, the agency cited stand-alone spectrophotometer systems where usernames were not attributable to specific individuals and a common username was used, no password was required to sign into the operating system, and analysts had the ability to delete and overwrite data. FDA’s remediation expectation was direct: unique usernames and passwords should always be used, and their confidentiality safeguarded.¹⁹

Note what that finding is really about. It is not that the computer was shared. It is that the audit trail could not attribute the action to a person. Everything in a shared-terminal design should be measured against that single question: can the record show who did this, without inference?

Patterns that work

The second-person verification problem

Many manufacturing steps require a verifier as well as a performer. On a shared terminal this is where designs break down, because the fast path is for the performer to stay logged in and hand the mouse over. That produces a record showing two signatures inside one session, which is exactly the pattern 11.200(a)(3) was written to prevent, since the second signature was executed under conditions where impersonation required no collaboration at all.

The fix is a design decision, not a training reminder. The verification signature should require a full component set from a different individual, and the system should reject a verifier whose identity matches the performer. Test both conditions. A separation-of-duties rule that exists only in an SOP will be the first thing an inspector probes when they see two signatures thirty seconds apart on the same terminal.

The Evidence That Has to Exist Regardless

Whatever authentication pattern you choose, a fixed set of artifacts has to exist for each signed record. These do not change with the identity architecture, which makes them a useful stable target when a platform team is proposing a change.

On the record itself

• Printed name of the signer, date and time of execution, and meaning of the signature, present in any human readable form of the record, on screen and in print.³ An initials field or a system-generated user ID alone does not meet the printed name requirement. The meaning has to be explicit, not implied by which button was pressed.
• A link between signature and record that prevents the signature from being excised, copied or otherwise transferred to falsify a record by ordinary means.⁴ In a system where the signature is a row in a table joined by a key, be prepared to explain what stops that row from being repointed.
• An audit trail entry recording the signing event, and recording any later change to the record. Part 11 audit trail requirements sat within the 2003 enforcement discretion, but the underlying predicate rules did not, and FDA said plainly that records must still be maintained in accordance with those rules.⁸ In practice, an inspector reviewing a signed GMP record will expect the audit trail to be there.

Behind the record

• Identity verification records under 11.100(b), covering the individual and any element of the signature, including elements assigned by an identity provider or an automated provisioning feed.²
• Uniqueness evidence under 11.100(a): the signature is unique to one individual and is never reused or reassigned. Test what happens when an employee leaves and a new hire receives a similar identifier. Directory reuse of a user principal name is a real risk in long-lived tenants.
• The certification to the agency under 11.100(c), matching the legal entity that operates the systems.²¹²
• Credential controls under 11.300: uniqueness of the combination, periodic checking or revision, loss management for badges and tokens, transaction safeguards that report attempted unauthorized use in an immediate and urgent manner, and initial and periodic testing of credential-bearing devices.⁵ The immediate and urgent reporting clause is the one most often unmet. A security operations dashboard nobody in quality reads is not a control until the escalation path is defined and exercised.
• A written accountability policy holding individuals accountable for actions initiated under their electronic signatures. FDA named this among the provisions it will continue to enforce.⁸

What federation adds to the evidence set

Moving authentication to an identity provider does not remove evidence obligations. It relocates them, and creates four new ones.

Three Patterns, and How to Choose

These three cover almost every real deployment. All three can be made compliant. They differ in where the control lives, how much they depend on session behavior, and how much rework they would need if the European draft language becomes final.

Pattern A: SSO for access, application-local signature credential

The identity provider handles log on, including MFA. The application maintains its own signature credential, typically a signing password or PIN distinct from the network password, and requires both the user identity from the session and that credential at each signing. Some deployments require the user name to be retyped at signing as well, which gives a full two-component execution every time.

Strengths: the signature control is entirely inside the validated application, so an identity platform change cannot move it. It is easy to explain and easy to test. Weaknesses: a second credential to manage, reset and age, and a second thing users can share. Password reset processes for the signing credential need the same rigor as the network one, which teams frequently forget.

Pattern B: SSO for access, step-up re-authentication at the identity provider for each signature

The application delegates the signing prompt back to the identity provider, requesting a fresh authentication with ForceAuthn in SAML, or max_age set to a low value with prompt=login in OpenID Connect, and constraining the acceptable authentication context.¹⁵¹⁶ The application validates the returned authentication time against the signing timestamp and records the method used.

Strengths: one credential for users, central control of authentication strength, and a clean upgrade path when the organization moves to phishing-resistant methods. Weaknesses: the control now spans two systems, so the interface and the identity provider configuration both fall inside the validated scope, and both need change control. This is the pattern that most often gets built correctly and then breaks later, when a well-meaning platform change relaxes the step-up policy.

Pattern C: no session reliance, full components at every signing

Every signing executes all signature components regardless of session state. The organization never invokes 11.200(a)(1)(i).

Strengths: the simplest possible compliance argument, immune to session configuration drift, and already aligned with the direction of the European draft. Weaknesses: highest user burden, and therefore the highest risk of credential sharing where signing volume is high. Best reserved for low-frequency, high-consequence signings.

What Belongs in the Validation File

The purpose of this documentation is narrow: to let someone reconstruct, two years from now, why this configuration was chosen and what evidence showed it works. Scope decisions about which systems need this treatment at all belong in the computerized system inventory, which a separate article in this series covers in detail. What follows assumes the system is in scope.

Conclusion

The tension between single sign-on and Part 11 is largely manufactured by treating login and signature as one event. They are not. The identity provider answers a question about access, which Part 11 addresses in one line at 11.10(d). The signature answers a different question about attribution, intent and meaning, which the regulation addresses in far more detail across 11.50, 11.70, 11.100, 11.200 and 11.300, all of which FDA named in 2003 as provisions it will continue to enforce. Once a design separates those two questions, the security team gets the consolidated identity it needs and the quality organization gets a signing act it can explain. The mechanisms to do this already exist in both mainstream federation protocols and have for years.

The judgment call that remains is the session boundary, and that one is genuinely yours. FDA gave you an access session, three conditions and no clock. The organizations that handle this well write down what a session means for each system class, tie those settings to change control so a platform tuning exercise cannot move a compliance boundary, and test the negative cases rather than only the happy path. The organizations that struggle inherited a timer from a default configuration and discovered during an inspection that nobody could say why it was set that way.

Sakara Digital works with pharma and biotech organizations designing identity and electronic signature controls that satisfy both the security team and the quality unit. If you are consolidating logins across a validated system estate and want an independent read on where your session boundary should fall and what evidence has to exist behind it, we are happy to have that conversation.

For Further Reading