If part of your Framer site uses page-level password protection — a client preview area, a private portfolio section — exporting requires actually thinking through how that protection gets replaced, since it doesn't come along automatically.
Why it doesn't survive a static export
Framer's password protection is enforced server-side, as part of Framer's hosting — a request for a protected page checks credentials before the content is served. A static HTML export is, definitionally, just files — there's no server-side gate built into plain static hosting to check a password against before serving a file.
What actually replaces it, by export type
Static HTML export: You'll need hosting-level protection instead of page-level. Most static hosts (Netlify, Vercel, Cloudflare Pages) support HTTP Basic Auth or similar access controls at the deployment level — coarser than Framer's per-page protection (it typically protects the whole deployment or a whole directory, not one specific page among many public ones), but functional for a genuinely private section.
Next.js export (runtime-intact): If your export keeps Framer's actual runtime running, password protection may continue working as before, since it's the same underlying mechanism — worth explicitly testing rather than assuming, since this depends on exactly how the export wraps the original page.
Next.js export (JSX/code-based): You'd implement your own auth check — even something simple like a middleware function checking a password against an environment variable before serving that specific route — genuinely more setup than Framer's built-in toggle, but gives you precise, per-page control rather than protecting an entire deployment.
The realistic recommendation
If you only need to protect one or two pages and the rest of the site should stay fully public, a Next.js export with a small custom auth check on just those routes is the most precise fit. If the entire section you're exporting is meant to be private (a whole separate portfolio subdirectory, say), hosting-level Basic Auth on that specific deployment is the fastest to set up correctly.
Either way — test the protected page specifically after any export. It's exactly the kind of thing that's easy to overlook while checking that the public pages all look right, and the failure mode (a "private" page that's actually now publicly accessible) is a genuinely bad one to discover late.