A two-factor electronic signature in one server-side step, and Protocol Studio arrives

In week 36 of 2026 (31 August to 6 September), the two-factor electronic signature in Burna AI became a single server-side step: the platform verifies the second factor and issues the signing credential in the same operation, and that credential can authorize one signature only. On 6 September, Protocol Studio launched for research sites, a trial began naming its own CTCAE version, and sign-off became the step that turns a reported symptom into a graded adverse event. The work serves investigators who sign grades, the quality and IT staff who answer a 21 CFR Part 11 review, and the coordinators who work from a protocol every day.

What a two-factor electronic signature needs under 21 CFR Part 11

Under 21 CFR 11.200(a)(1), an electronic signature not based on biometrics must "employ at least two distinct identification components". Section 11.50 requires a signed record to show the signer's printed name, the date and time, and the meaning of the signature, and section 11.70 links the signature to its record so it cannot be copied or transferred.

The second component used to arrive as two separate calls from the browser: verify a one-time code, then issue a credential. Nothing tied the credential to the verification, so the second call worked for anyone with a live session. From 31 August, one server-side step does both:

	Before	Now
How the second factor is checked	Two browser calls, and the second worked without the first	One server-side step that verifies the factor and issues the credential together
What the credential records	No factor at all	The factor presented and the time, with only a one-way digest of the credential stored
How long the credential lasts	24 hours	5 minutes, and it can be spent once
What counts as the second component	The session itself, so the code could be skipped	A one-time code sent to the signer's email

How the signing credential is protected

• The signer is the session's own user. A request cannot name someone else as the signer.
• A password is not a second component. Re-entering the password does not count, because the session already rests on the password.
• Every refusal looks the same. A wrong code and an unrecognized factor are refused alike, so a caller cannot learn which factors a signer holds.
• One credential, one signature. Spending the credential is one database statement, so two signings cannot both succeed on the same credential.

Two more Part 11 changes landed with it. Governed actions are chained in order under a cryptographic seal, and a new signature is appended as a row that names the version it signs, never written over an earlier one. How e-signature works on grading decisions answers the short question, and a 21 CFR Part 11 checklist for AI-assisted adverse event grading maps each requirement to the regulation.

Protocol Studio launches for research sites

Protocol Studio, a Burna AI product line, launched on 6 September. It reads a trial's protocol together with the documents that come with it, and gives a site's coordinators and investigators one place to work from them. The same day, its own app and site were provisioned to run at protocolstudio.ai.

What launched:

• Two tiers in one product. A coordinator tier that holds no patient data, and a tier with chart access that runs under a business associate agreement.
• Conformance findings that quote both sources. Where passages in a document set give opposite instructions, the finding shows both passages and both sources, and Protocol Studio does not choose between them.
• Amendments and clarifications as records. A sponsor's written clarification is kept with the protocol sections it answers, and an amendment that changes that text puts the clarification under review until a reviewer records the review.
• An ICH M11-shaped structure. Using the section order of ICH M11, extraction lists every section of a protocol in order, names the sections it did not find, and carries a page reference on each element it bound.

The trial names its CTCAE version, and every grade records it

The CTCAE version decides the criteria a grade is measured against: of the 790 terms v5.0 and v6.0 share by name, 376 are worded differently at one grade or more. This is the week after CTCAE v5.0 went live beside v6.0. A grade without its version cannot be checked later by a monitor or a sponsor. From 6 September:

• The trial names its version. A trial records the CTCAE version its protocol names, and a trial that has not stated one is kept distinct from a trial that chose v5.0.
• Every graded row records its version. Each graded adverse event stores the version that produced it and where that choice came from: the clinician, the trial or the platform default.
• The choice comes before the run. Clinicians pick the version on the capture screens, before grading starts, and the grading instructions follow the version chosen.
• Search names what it shows. CTCAE search serves both versions, v5.0 by default, and names the version whose criteria it is showing.

Sign-off creates the graded adverse event

Symptoms a patient reports before a visit now become grading proposals. A symptom reported many times leaves one open proposal and a history of the superseded ones, and a proposal becomes a graded adverse event only when a clinician signs it. AI suggests, clinicians decide, and the record now has the same shape:

• Override and discard each need a written reason. A blank reason, or one made only of spaces, is refused on the screen and on the server.
• An unsigned AI grade looks unsigned. It carries a dashed border and the label "Proposed, not yet reviewed", while its grade color stays, so a reader scanning for a grade 4 still finds it.
• Billing happens once, at sign-off. A graded encounter is billed at one rate for every customer. A second signature on the same visit, such as an addendum or a corrected grade, is recorded and charges nothing, and a billing failure never blocks a signature.

The organization boundary, checked at build time

A multi-site trial means one deployment holding several organizations, and the boundary between them is the first thing a security review asks about. On 31 August, the organization id became its own type, produced only by a small set of resolvers that each read an authority the caller cannot assert. A function that needs a verified organization cannot be called with an id read from a request body, and that mistake now fails the build.

The same work also means:

• Membership is checked at every token. Membership is checked again each time an organization-scoped token is issued, and removing a member updates their sessions.
• Uploads wait for a scan. An upload is held until a scan releases it, and a held download says why.
• Model requests are rate-limited. Requests that reach the language models are rate-limited by verified organization.

The architecture a security review asks about is set out on one page.

Support attachments under a write-ahead audit

Support tickets now deliver their attachments, up to three files of 2 MB each, in a fixed order: validate the attachments, write the disclosure to the audit trail, post the ticket, then upload the files into its thread. A screenshot of a patient chart is clinical data leaving the platform, so if the audit trail cannot record the disclosure, the contents are withheld, the ticket is still saved, and the support team sees which ticket it was.

Also in week 36

• Blind grading roster access restored. Organization owners and administrators regained access to their blind grading roster.

Since then: Protocol Studio runs at protocolstudio.ai, where a research site can start with a free protocol conformance report.

AI suggests, clinicians decide. Human-in-the-loop, always.

To walk through the Part 11 signing ceremony with your quality team, book a 15-minute conversation.