Native Electronic Signature Support – A Breakthrough for 21 CFR Part 11 Compliance

The newly released Ignition 8.1.16 introduces native support for collecting electronic signatures with Ignition Perspective applications. This is more than a convenient upgrade; it’s a significant achievement, especially for Life Sciences customers, where electronic signatures are often subject to strict regulations.

To better explain why this is such exciting news, in this post I’ll discuss the current regulatory landscape around electronic signatures and some advantages of Ignition’s new native electronic signature feature compared to the traditional approach to electronic signature collection. I’ll conclude with a technical walkthrough, showcasing a real-life example of how you can take advantage of this new functionality in your own applications today.

A Brief History

Firstly, it’s worth providing some context and clarifying what we mean by an “electronic signature,” specific to certain regulated applications. To be clear, we are not talking about digital signatures or handwritten signatures captured via Ignition’s Signature Pad component.

Many manufacturing companies, such as those in the FDA-regulated Life Sciences industry, have strict requirements around recordkeeping. In the past, these records were primarily paper-based and thus required handwritten signatures for sign-off. As the adoption of computerized systems increased, many of these records started to be generated electronically. Rather than require that these electronic records be printed out and hand-signed, regulations evolved to accept many kinds of records in their original electronic format. Therefore, these records would require an electronic alternative to handwritten signatures.

What is an Electronic Signature?

FDA-regulated companies and their partners are undoubtedly familiar with 21 CFR Part 11, which is shorthand for Part 11 of Title 21 of the US Code of Federal Regulations. Part 11 defines electronic signatures as the following:

Electronic signature means a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual's handwritten signature.

Although Part 11 is specific to the US, other geographies often have their own standards or guidelines, such as EU Annex 11 in Europe, which similarly stipulate requirements for electronic signatures.

Included in Part 11 are the specific conditions under which the FDA will recognize electronic signatures as being equivalent to handwritten signatures. Meeting these conditions and complying with the rest of Part 11 is ultimately the responsibility of the end user, since compliance requires implementing controls beyond what an out-of-the-box SCADA system typically provides. With that said, Ignition has provided key enabling features for building compliant systems.

Collecting Signatures with validateUser()

One of Ignition’s key features for building Part 11-compliant systems is the system.security.validateUser() function, which allows an application to validate user credentials against authentication providers on demand, rather than just at application login. This is important for performing a signing operation and is particularly effective when paired with an authentication provider like Microsoft Active Directory, which offers rich configuration settings to meet the electronic signature password requirements of Part 11.

By building on this key feature and other existing features like audit logs, Ignition applications like 4IR’s PharmaStack™ platform have been able to build custom solutions for managing Part 11-compliant electronic records and signatures.

Challenges

However, building a compliant solution on top of this user validation function comes with a couple of caveats.

Firstly, the function can only validate against a User Source, not an Identity Provider. Companies who are using external Identity Providers like Okta or Azure Active Directory, which are not linked to a User Source, would have to configure a dedicated User Source (such as an on-premise Active Directory server) just for collecting signatures. This User Source would need to be set up, maintained, and synchronized with the Identity Provider to ensure compliance.

Secondly, calling system.security.validateUser() to generate a signature requires the application developer to collect a password from the user, which could create a security risk in the case of a malicious actor or if the password is inadvertently leaked through a seemingly innocuous logging command. If a company is using an Active Directory-linked User Source or otherwise synchronizes the password with an external Identity Provider, this security risk could extend to other applications that use the same authentication provider.

Native Electronic Signatures to the Rescue!

Fortunately, Ignition’s new native electronic signature support addresses both of the aforementioned issues with validateUser() by enabling secure, on-demand authentication using Identity Providers. Let’s walk through an example.

Example Using an External Identity Provider

To use the new electronic signature support, an Identity Provider must first be configured. You can use either Ignition’s built-in internal Identity Provider or an external Identity Provider that supports SAML or OpenID Connect.

Once an Identity Provider has been set up, you can use the new system.perspective.authenticationChallenge() function to redirect users to an Identity Provider to perform the authentication process. In the example below, we trigger this function call when one of the “Sign” buttons is clicked.

This function supports several optional parameters that can impact its behavior, including a payload and a framing option. In this case, we are using the default “self” framing option (which is supported across all Ignition clients), which redirects the user away from Ignition and over to the configured Identity Provider to step through the authentication process.

If the user successfully completes the authentication process, they will be redirected back to the Ignition application, and a newly added Perspective Session Event Handler called “Authentication Challenge Completed” will be triggered that contains the result of the authentication process, the optional payload that was previously sent, and a Session object, which your application can use to react to the authentication attempt.

To achieve the example below, we are using custom Session properties that allow us to reconstruct the view state, verify appropriate user roles, and provide a visual confirmation of the signature.

Final Thoughts

With 8.1.16, Ignition now provides a powerful framework for collecting electronic signatures from Identity Providers. Future releases will build on this framework by adding deeper integration with existing Ignition features like the tag and auditing systems, making it easier to support common use cases and to meet other Part 11 requirements.

Of course, beyond simply collecting signatures, there are a host of other requirements to Part 11, such as assuring data integrity, that must be met in order to achieve regulatory compliance. If you are a Life Sciences manufacturer or partner who is looking for additional guidance, connect with the 4IR team and ask about our PharmaStack™ platform, which includes pre-built templates and documentation for accelerating your path to compliance with Ignition.