EPCS requires two factors. It does not require the prescriber.

Electronic prescribing of controlled substances is one of the few places in American healthcare where a regulator demanded a signature on an individual act rather than a login. That was the right instinct. The problem is that the two factors authenticate a person into a session, and the session is what signs the order.

A Thursday evening on the ward

It is 6:40pm. The attending has eleven orders queued in the electronic health record, four of them controlled substances, and she is standing at a shared workstation outside room 12 because the workstation in the physician area is being used by someone doing discharge summaries.

She signs in. The system asks for her second factor. Her hard token is in the pocket of the coat she left in the physician lounge, three corridors away, because it has a lanyard clip that catches on everything and she stopped wearing it in month two. A resident who is standing next to her, who has his own token because he is newer and has not yet developed the habit of leaving it behind, offers to walk down and get hers.

He comes back with it. She taps through the four controlled substance orders in about forty seconds. Everything about this is normal. Nobody has done anything they would describe as wrong. The orders were clinically correct, she intended every one of them, and the patients got appropriate care.

Now change one detail. She does not walk to the workstation at all. She is in a meeting. The resident has her token, because he fetched it an hour ago and she has not asked for it back, and he knows her password because she read it out to him over the phone last week when the system locked her out. He signs the four orders. Three of them she would have signed. One of them she would have questioned.

The audit log for both versions of this evening is identical.

What does 21 CFR Part 1311 actually require?

Before criticising anything, it is worth stating plainly how much better this rule is than what surrounds it. Most of healthcare security is a login. This one is not.

The Drug Enforcement Administration's regulations on electronic prescriptions for controlled substances, at 21 CFR Part 1311, impose a set of requirements that would be considered unusually strict almost anywhere else in enterprise software.

Identity proofing before the credential exists

A practitioner cannot simply be given EPCS capability by an administrator. The rule requires identity proofing, either through a credential service provider or certification authority meeting the assurance levels the rule references, or, for practitioners at an institution, through the institution itself acting under specified conditions. The rule's assurance language references the NIST framework as it stood when the rule was written, which is a detail worth remembering when you compare it to current NIST terminology, since the vocabulary has since been reorganised into separate identity, authenticator and federation assurance levels.

The point is that the DEA did not treat the prescriber's identity as an administrative fact. It treated it as something that must be established against evidence before any signing capability is granted.

Two factors, and one of them cannot live on the computer

The signing step requires two of three factor types: something you know, something you have, and something you are. The detail that makes this stronger than typical enterprise multi factor authentication is the constraint on the second factor. If a hard token is used, it must be separate from the computer being used to access the application. A software token sitting on the same workstation does not satisfy the requirement.

Think about how rare that is. Most enterprise MFA is perfectly happy with an authenticator app on the same laptop that is doing the work. The DEA said no, and said it in 2010, which was well ahead of where the rest of the industry was thinking.

The signing act, not the session

The rule requires the two factor authentication to be applied to the act of signing the prescription. This is the part that matters most for our purposes and the part that most people misremember. The requirement is not that the prescriber logged in with two factors at the start of a shift. It is attached to signing.

Logical access controls and audit trails

The rule also requires controls over who can be granted signing capability inside an institution, with separation of duties in how that access is set, and it requires the application to maintain audit trails and to run internal audits that check for specified auditable events.

So: proofed identity, two factors with a real separation requirement, applied per signing event, with access control and audit obligations. If you had described that specification to a bank in 2010 they would have been impressed.

So why is there a problem at all?

Because there is a gap between what the rule requires and what the rule can observe, and every one of the failure modes lives inside that gap.

Here is the precise technical statement. The two factors prove that, at some moment, someone presented a password and a token that belong to the prescriber. The application then treats the resulting authenticated state as authority to sign. What the signature covers, cryptographically, is a record inside the application saying that this authenticated user approved this order. There is no artifact binding the prescriber's possession of the second factor to the specific content of the prescription in a way that anyone outside the application can check.

An analogy. Imagine a bank that requires you to show your passport and put your thumb on a reader before you enter the signing room. Once you are in the room, you can sign any document on the table, and the record of the transaction says "verified individual signed this document" with no signature from you on the document itself. That system is much better than one with no door checks. It still cannot tell you afterwards which of the documents on the table you actually read, or whether you were even in the room when the last one was signed, because the evidence lives in the door, not on the paper.

This is the failure this blog calls Session Inherited Authorization, and it is the same shape as the one we describe in session theft and adversary in the middle attacks and in approval workflows that run over email and chat. The authentication event and the consequential act are separated in time, and everything between them inherits authority from the first without being bound to it.

Where does the rule meet the ward?

Rules are written in offices. They are executed at 6:40pm on a shared workstation. Three specific practices open the gap, and none of them is exotic.

The token that never leaves the drawer

Hard tokens are lost, forgotten, left in coats, and left in drawers next to the workstation for convenience. The rule's separation requirement is defeated the moment the separate token lives permanently next to the computer it is supposed to be separate from. This is not a compliance failure that a policy memo fixes, because the underlying cause is that carrying a small object all day, every day, without ever forgetting it, is not something humans reliably do.

Delegated order entry

Clinical work is team work, and a great deal of order entry is legitimately prepared by nurses, scribes, and residents before an attending reviews and signs. That is good medicine and the workflow exists for sound reasons. The risk appears when the preparation and the signing collapse into a single act performed by the person who prepared it, using credentials that belong to someone else. The rule prohibits this. The workflow makes it convenient. Convenience wins more often than anyone would like to write down.

The shared workstation

Fast user switching, tap and go badges, and always logged in clinical workstations exist because a clinician who spends ninety seconds authenticating per patient encounter will see fewer patients. Every one of those speed optimisations widens the window in which an authenticated session exists without the authenticated person standing in front of it.

It is important to say clearly: the overwhelming majority of prescribers are not diverting anything. Framing this as a hunt for bad clinicians gets the problem wrong and guarantees that no clinician will help you fix it. The right framing is that a prescriber's DEA registration is one of the most valuable credentials in the building, and the current design gives its owner no way to prove which orders were actually theirs. When a credential is misused, the prescriber is the person with the most to lose and the least evidence to defend themselves with.

What changes when an AI assistant drafts the order?

This is the part that is genuinely new, and it deserves a careful rather than an alarmed treatment.

Clinical AI systems are moving into order entry. They draft, they reconcile medication lists, they suggest, and in some configurations they queue orders for signature. Most of this is useful. Reconciliation in particular is tedious, error prone human work that machines do well.

But now ask the question that Part 1311 was never written to answer. When a prescriber applies two factors to sign an order that a model drafted, what exactly is being attested?

There are two possible readings and the system records neither. The prescriber may have read the order carefully, checked the dose against the patient's renal function, considered the interaction with the other three medications, and formed an independent clinical judgement. Or the prescriber may have tapped through a queue. The audit trail is identical in both cases, and so is the legal weight of the signature.

This is the same question that arises in every regulated domain where machines now draft records that humans sign, and it is unresolved in all of them. It is the reason the FDA's electronic records and signatures framework, written in 1997, is being re-examined for machine drafted work.

The sharper version of the risk is what this blog calls Approval Theater: a human in the loop control that the machine can satisfy. If an assistant can trigger the same push notification that the prescriber approves, or can drive the same workstation flow, then the human oversight step is inside the system being overseen. The control has been placed on the wrong side of the airlock.

What would it mean for the second factor to sign the prescription?

The fix is not a new device, a new rule, or a new vendor category. It is a change in what the second factor covers.

Today, the second factor answers: is this the prescriber? Tomorrow, it should answer: did this prescriber approve this order, with these contents, at this moment?

Concretely, that means the application takes the prescription content, produces a canonical representation, hashes it, and uses that hash as the challenge for the authentication ceremony. The prescriber's device signs the hash. The signature therefore covers the drug, the dose, the quantity, the patient reference and the timestamp, and it cannot be transferred to a different order because a different order produces a different hash.

Here is the payload, conceptually, as it would appear before hashing.

{
  "type":        "epcs.prescription.sign",
  "prescriber":  { "npi": "1234567890", "dea_ref": "sha256:4a1f...9c02" },
  "patient_ref": "sha256:9f2b...c41a",
  "drug":        "oxycodone HCl 5 mg oral tablet",
  "quantity":    30,
  "days_supply": 5,
  "directions":  "1 tablet PO q6h PRN moderate pain",
  "refills":     0,
  "written_at":  "2026-09-26T18:41:07Z",
  "prepared_by": "assistant:cpoe-draft-v3",
  "delegation":  null,
  "nonce":       "b7c1e0d4a9f35128"
}

Note two fields that do not exist in any EPCS flow today. The prepared_by field records that a machine drafted this order, which means the record itself distinguishes an order the prescriber composed from one the prescriber reviewed. The delegation field is null here, and would carry a scoped, expiring delegation record in the workflows where preparation by another party is legitimate and intended.

The signing ceremony then looks like this.

digest    = sha256(canonical_json(payload))
assertion = authenticator.sign({
              challenge: digest,
              userVerification: "required"    // biometric or PIN on the device
            })

receipt = {
  payload, digest,
  credential_id: assertion.credentialId,
  signature:     assertion.signature,
  signed_at:     "2026-09-26T18:41:09Z"
}

// Any party holding the published key can check this. No callback.
verify(receipt, published_key)   // -> true

The last line is the one that matters most and it is easy to skim past. The receipt verifies against a published key. A pharmacy, a state board investigator, a hospital's own auditor, or the prescriber defending themselves three years later can check it without asking the electronic health record vendor whether its log is accurate. The evidence stops being something the application asserts about itself and becomes something a third party can independently confirm. We wrote about why that property matters generally in verifying credentials without calling the issuer.

What this does to the three ward practices

The token in the drawer stops helping, because the signature requires user verification on the prescriber's own enrolled device, which is typically the phone in their pocket rather than a fob that can be handed over. Handing over a phone with a biometric unlock is a meaningfully different act from handing over a fob, socially and practically.

Delegated signing becomes visible rather than invisible. Where a delegation is genuinely intended, it is recorded in the payload as a scoped, expiring grant rather than happening silently through credential sharing. Where it is not intended, the signature cannot be produced by the person preparing the order.

The shared workstation stops being the problem, because the workstation is no longer the thing that holds authority. The prescriber can walk up to any terminal in the hospital, and the signature comes from their device.

What each EPCS requirement leaves open

Honest limits

This section matters more than the proposal, so read it before you quote anything above.

Manav is not a DEA certified EPCS application, and a signature alone does not make anyone compliant. The DEA rule prescribes permitted authentication methods and requires the application itself to be certified by a qualified third party auditor or certification body. An order bound signature can serve as a factor within a compliant application, but only the electronic health record or prescribing platform can carry the certification. Nothing in this post should be read as a claim that adopting a receipt satisfies Part 1311. That determination belongs to the vendor, the institution, and their auditors.

This is not regulatory or legal advice. If you are responsible for EPCS compliance, your controlling documents are the regulation, your certification report, and your counsel.

A signature does not verify clinical judgement. A prescriber who taps through a queue of machine drafted orders on their own phone has still signed them. Binding the signature to the order records what was signed and by whom. It does not record whether anyone thought about it. Anyone who claims otherwise is selling something.

A determined prescriber can still divert. The person with the registration is the person with the authority, and a control that proves they authorised the order is exactly what you want in a diversion investigation, but it does not prevent someone from writing prescriptions they should not write. This closes credential misuse, not misconduct.

Emergencies and connectivity are real constraints. On call prescribing at 3am from a rural site with poor signal is a workflow that must keep working. Any design must have an offline or degraded path, and that path is where controls usually leak.

Adoption is the hard part, not cryptography. The signing step lives inside the electronic health record. Changing it requires the vendor to build it and the institution to deploy it. Epic, Oracle Health and athenahealth could each add device bound signing to their EPCS flow. What none of them would produce on their own is a prescriber enrollment that works across every platform and health system, or a receipt a pharmacy can verify without trusting the sending system. That is the part worth building once rather than seven times.

What to do this week

1. Ask your EPCS vendor one question in writing: is the second factor cryptographically bound to the contents of the prescription, or does it authenticate the user to the application? Keep the answer.
2. Pull your own audit data on token usage. Look for tokens whose usage pattern suggests they live at a fixed workstation rather than moving with a person.
3. Count how many controlled substance orders in the last quarter were prepared by a party other than the signer, and whether your system records that fact at all.
4. Find out whether any clinical AI system in your environment can trigger the authentication prompt that a prescriber approves. If it can, you have an approval theater problem regardless of what else is true.
5. Add a field to your order records that distinguishes machine drafted from clinician composed orders. You will want this data long before anyone requires it.
6. Review your delegated order entry policy against actual practice on two wards. Not the policy. The practice.
7. Ask your privacy and compliance leads what evidence they would produce if a prescriber disputed an order attributed to them. If the answer is the EHR log, note that the log is written by the system being questioned.

Frequently asked questions

Can an AI assistant or staff member complete the second factor for an EPCS prescription? No. The DEA requires the prescriber to apply the second factor to the signing of each controlled substance prescription, and prohibits delegating that credential. The practical difficulty is that current implementations cannot distinguish a prescriber applying their own factor from someone else applying the prescriber's factor, because the factor authenticates a user rather than signing the order.

Is push notification multi factor authentication compliant for EPCS? That depends on the implementation and on the certification of the application, and it is a question for your auditor rather than for a blog. The design concern is separate from compliance: a push prompt that says only "approve sign in" does not tell the prescriber what they are approving, and can often be triggered by any process able to start the flow.

What does 21 CFR Part 1311 require for identity proofing? Practitioners must be identity proofed before receiving signing capability, either through a credential service provider or certification authority meeting the assurance levels referenced in the rule, or through an institution acting under the conditions the rule sets out for institutional practitioners. The proofing happens once, before the credential is issued.

Does a device bound signature satisfy the DEA two factor requirement? Not by itself, and not by our say so. The rule specifies permitted factor types and requires the application to be certified. A device signature with user verification exercises two factor types in a single ceremony, which is the shape the rule contemplates, but whether a given implementation qualifies is determined by the certification process and the DEA, not by the vendor of any component.

What is the risk when clinical AI drafts controlled substance orders? Two things. First, the signature records that a prescriber approved an order without recording that a machine composed it, so the provenance of the clinical reasoning is lost. Second, if the assistant can trigger the same approval prompt the prescriber responds to, the human oversight step sits inside the system it is meant to oversee.

Who benefits most from order bound signing? Prescribers. Their DEA registration is a high value credential that they currently cannot prove they did or did not use on a given occasion. A receipt they hold is the only artifact that lets them demonstrate which orders were genuinely theirs, which matters in exactly the situations where their livelihood is at stake.

Sources

1. Electronic Prescriptions for Controlled Substances, 21 CFR Part 1311, eCFR.
2. DEA Diversion Control Division, electronic prescribing resources and rulemaking, deadiversion.usdoj.gov.
3. NIST Special Publication 800-63, Digital Identity Guidelines, pages.nist.gov/800-63-3.
4. US Department of Justice, public announcements on healthcare and controlled substance prescribing enforcement, justice.gov/news.
5. Centers for Medicare and Medicaid Services, electronic prescribing of controlled substances under Medicare Part D, cms.gov.
6. W3C Web Authentication (WebAuthn) Level 2, w3.org/TR/webauthn-2.
7. Manav developer documentation on per action signing and receipts, manav.id/docs. See also the signing demo.

The DEA asked for two factors at the moment of signing, which was ten years ahead of its time. It just never got to say that the factors should sign the prescription rather than the prescriber.