If you lock down the frontend, that is often sufficient to keep users out of mischief.  It depends on how savvy or determined your users are.  Even with security, the determined can hack their way in.
Be sure to create custom menus/toolbars for use throughout your application; create a startup form (a main menu form if you have one) that is opened on startup.
Use the features in Tools, Startup to
       set the startup form
       set your default menu (the custom one you made)
       disable all the checkboxes about allowing built in menus, toolbars, changes etc.
       hide the db window (ensure the custom menu you create does not include the Windows, Unhide item)
       disallow special keys (this will disable the F11 key, among others)

If you need to bypass these startup features, you can hold the shift key down while you open the db.  If you feel that your users may use this to bypass your settings, you can disable the shift key bypass - there's an example in help for doing this(look for AllowBypassKey) or at
http://www.mvps.org/access/modules/mdl0011.htm
and
http://www.mvps.org/access/general/gen0040.htm

You can also create a MDE from your database, which will prevent changes to forms, reports and modules (If you do this, be certain to keep your original mdb in case you need to make changes).

If you do implement security, you'd secure both the FE and BE using the same workgroup file.  Be sure to follow a set of steps to ensure you implement security properly.  See www.jmwild.com/AccessSecurity.htm

Don't use the splitter wizard on a secure database as that will remove the security on the BE, but leave the FE secure.  Instead, split it manually.  See www.jmwild.com/SplitSecure.htm

Here's my opinion <g>

Splitting and changing to mde are quite separate things. Both are recommended.

Splitting is for speed, and it is claimed for reliability. MDE is to prevent
your code being looked at (and that's all)

I note that Oracle has "gone off" the Client/Server model since 1995. Although
Access FE/BE splitting is only a poor cousin of true Client/Server, it
nevertheless attempts to simulate the same thing. (ref: "SOFTWAR, Larry
Ellison and Oracle", Matthew Symonds, Simon & Schuster). Nevertheless, and
apart from a web-based model which I believe Access can support, Access is
best served by "splitting".

Access Security is only usefull in a "low-risk" environment. That said, it is
nevertheless usefull because "most environments" are, arguably, "low-risk". It
stops lesser than "experts" or "determined entities" getting into it!

It is your call whether additional security is worthwhile. For a single
single-user site, I don't bother. Otherwise I implement full Access Security,
because it's the best you can do with Access.

The way I implement Access User Level Security, which may or may not be the
best way but it's certainly simple, is that I write my program/database as a
single file, implement security, then take a copy of the hopefully finished
database. One copy becomes the Back-End by removing everything EXCEPT Tables
(and Relationships if set). The other copy becomes the Front-End by removing
the Tables (replacing them with links) AND Relationships if set. Although
Relationships can remain with linked tables, they do nothing in that case.

Voila! Fully ULS secured, and I only had to do it once! I am not sure, because
I don't use it, of the steps required to use the "Security Wizard". Every
"copy" of an mdb/mde carries ULS with it.

It is said, with good reason, that ULS Security is "difficult to implement".
Certainly, one needs to follow the SECFAQ document here:
http://support.microsoft.com/default.aspx?scid=%2Fsupport%2Faccess%2Fcontent%2
Fsecfaq.asp

I think Access ULS security is worthwhile, because it's generally the best you
can do with Access! However, if you are developing something anew, be aware
that Access2007 has dropped the secirity model (except for legacy-mode). I
don't know what you are supposed to do with A2007!

Chris

Thank you both - it was a big help.
D