A Two-Sentence Notice for 941,000 Patients
On September 28, Florida's Office of Medical Marijuana Use started requiring multifactor authentication for anyone logging into the state's Medical Marijuana Use Registry, citing Rule 60GG-2, the state's cybersecurity standard for business-to-citizen system access. The announcement was two sentences on the OMMU homepage. No FAQ, no rollout guide, no advance notice beyond the posting itself.
That's a small thing to some people. It isn't, really. As of early September, Florida counted 941,509 active medical marijuana cards, and every one of those patients logs into the same registry to submit applications, track order status, and check how much of a physician's authorization they still have left to fill. Add physicians, caregivers, law enforcement, and dispensary staff to that user base, and you get a system holding some of the most sensitive data a state collects: identity, diagnosis, and legal medical status, all in one record.
The Rule Is New. The Risk Was Not.
Multifactor authentication for citizen-facing government systems isn't a novel idea in 2026. NIST has recommended it for years, and plenty of states already require it for tax portals, unemployment claims, and benefits systems. What stands out about Florida's registry is that a system holding this much sensitive personal health data ran on username and password alone until three weeks ago.
cloudPWR builds and supports HIPAA-oriented cannabis registry infrastructure, including South Dakota's statewide medical cannabis patient and provider registry. Registries like these sit at an odd intersection: they're state government systems, so they inherit government cybersecurity standards, but they also hold health information, so they inherit healthcare-grade privacy expectations too. A registry that only clears the lower of those two bars is exposed on the higher one.
A patient record in a cannabis registry links identity, health status, and legal standing in a way most residents assume the state already keeps locked down. Username and password was never going to be enough.
What Governed Access Actually Looks Like
Adding MFA at login is a start, not a finish. OMMU's notice doesn't say whether the requirement covers dispensary staff who record dispensations in real time, whether it applies to every login or just new devices, or how a patient who hasn't touched the registry since last year's renewal is supposed to find out before they're locked out mid-renewal. Those are exactly the scoping questions a system's design should answer before a compliance deadline forces the issue, not after.
In our experience building registry systems, that means role-based access defined at the account level, so patients, providers, dispensary staff, and state reviewers each see and can do different things. It means MFA enforced as a baseline assumption rather than a patch applied under a rule citation. And it means every login and data touch lands in an audit trail a compliance officer can actually read, instead of one somebody has to reconstruct from raw server logs after something goes wrong.
The Pattern to Watch
Florida isn't acting alone here. Georgia adopted a GovRAMP mandate for state contracts this year. Washington State cannabis regulators are asking for close to $12 million to replace their aging traceability system. States that built cannabis and health registries a decade ago are running into the gap between what those systems were designed for and what current cybersecurity standards now expect of them.
For an agency IT director evaluating a registry vendor, or auditing one already under contract, the useful question isn't whether MFA is turned on today. It's whether the system was built with governed access as a starting assumption or added it after a rule changed. cloudPWR designs its registry work and AIRLIFT Connect pipelines around the first answer, with SOC 2 Type II certification, GovRAMP membership, and HIPAA-oriented controls in place from day one, not backfilled after a two-sentence policy notice forces the question.