What happened to Access workgroup security in .accdb?

Microsoft removed workgroup security entirely when they introduced the .accdb format with Access 2007. The .mdw workgroup file, user-level security, and the User-Level Security Wizard no longer exist in .accdb databases. This security model was considered outdated and too easily bypassed.

Can I open a .mdb with workgroup security in .accdb format?

You can convert the database structure, but the workgroup security settings don't migrate. After converting to .accdb, the user-level permissions are gone. You need to implement Access 2007+ security features (database passwords, form-based authentication, or Windows file permissions) to replace the workgroup security you had in .mdb.

What is the .mdw file in Access?

The .mdw (Microsoft Database Workgroup) file is the workgroup information file used by Access 2003 and earlier to store user accounts, group memberships, and permissions for Jet database security. Each user had to join the workgroup by pointing Access to the .mdw file. This entire security system was replaced in Access 2007 with .accdb.

How do I secure an .accdb database?

There are three main options: (1) Database password — a single password required to open the .accdb file, set via File > Info > Encrypt with Password; (2) Windows NTFS file permissions — control who can read/write the .accdb file at the OS level; (3) Form-based security — custom VBA login form that checks credentials against a users table and controls navigation. For multi-user applications with role-based access, the hybrid approach (Access front-end + SQL Server back-end) uses SQL Server's robust security model.

Access Security Model Changes — From Jet Workgroup Security to ACE

April 21, 2026 · 8 min read

If you're migrating an older .mdb database to .accdb and your database used Jet's workgroup security — the .mdw file system with user accounts, groups, and object-level permissions — you need to know this before you start: that security model doesn't exist in .accdb.

Microsoft removed workgroup security entirely when they introduced the .accdb format in Access 2007. The .mdw file, the User-Level Security Wizard, the SID-based permission system — all gone. After migration, your database is open to anyone who can open the file, unless you implement a replacement security model.

This guide explains what was removed, why, and what your options are for securing .accdb databases that need access control.

What Jet Workgroup Security Was

Jet workgroup security was Access's built-in multi-user access control system, available in .mdb databases from Access 2.0 through Access 2003. It worked like this:

A workgroup information file (.mdw) stored user accounts and group definitions
Every user had a username and password stored in the .mdw file
Permissions were set per object (table, query, form, report) per user or group
The Admin account was always present; removing all its permissions was required to actually secure a database
Users joined the workgroup by pointing Access to the .mdw file at startup

Workgroup security gave you genuine role-based access control: read-only users who could run reports, data-entry users who could add records but not modify structure, admins who could do everything.

It was also notoriously easy to bypass. The .mdw file was just a database file. Tools existed to crack or reset workgroup passwords. Microsoft eventually concluded that the security model wasn't strong enough to justify maintaining.

What Was Removed in .accdb

The complete Jet workgroup security stack was removed in Access 2007 (.accdb):

.mdw workgroup files — no longer supported or opened by Access 2007+
User-Level Security Wizard — removed from Access 2007+
Object-level permissions — no table/query/form permission system exists in .accdb
User accounts and groups in Access — Access no longer manages users internally
Jet SID-based ownership — the ownership model tied to workgroup SIDs is gone

Important

When you convert an .mdb with workgroup security to .accdb, the conversion succeeds — but all workgroup security settings are silently dropped. The resulting .accdb is completely open. Anyone who can open the file has full access to all objects.

What Also Changed: The Sandbox Mode

Along with workgroup security, Access 2007+ introduced Sandbox Mode — a security feature that runs certain VBA expressions through a safer evaluation engine. This affects:

Shell() function — blocked in Sandbox Mode by default
Some file system functions — restricted in untrusted databases
Certain action queries — controlled by Trust Center settings

In .mdb databases, these functions ran with fewer restrictions. After migration to .accdb, if your VBA uses Shell() or similar functions, users may see security warnings or failures until the database is added to a trusted location or the Trust Center is configured appropriately.

Replacing Workgroup Security in .accdb

You have four options for securing .accdb databases. Choose based on your requirements:

Option 1: Database Password (Simple, Single-Level)

Access 2007+ supports a single database password that encrypts the file and requires entry at open.

How to set it: File menu → Info → Encrypt with Password. Enter and confirm the password.

What this gives you: nobody can open the database without the password. Suitable for databases where everyone with access should have full access.

What this doesn't give you: role-based permissions. All users with the password have identical access. No user-level control.

Option 2: Windows NTFS File Permissions (Infrastructure-Level)

Control who can open the .accdb file at the OS level using Windows folder and file permissions. Read permission allows opening the database. Write permission allows saving changes.

What this gives you: different users can have read-only vs read-write access to the file. Simple to manage through Active Directory groups. No changes to the Access database required.

What this doesn't give you: object-level control within the database. A user with file read-write permission can modify any table, not just permitted ones. Suitable for trust-based environments where all authorized users should have similar access.

Option 3: Custom Form-Based Security (VBA)

Build a login form in VBA that checks credentials against a users table in the database. Control navigation and feature access based on the logged-in user's role.

' Example: Login form validation
Private Sub cmdLogin_Click()
    Dim rs As DAO.Recordset
    Dim sql As String

    sql = "SELECT UserRole FROM tblUsers " &
          "WHERE Username='" & Me.txtUsername & "' " &
          "AND Password='" & Me.txtPassword & "'"

    Set rs = CurrentDb.OpenRecordset(sql)

    If Not rs.EOF Then
        ' Store role in global variable for navigation control
        gstrUserRole = rs!UserRole
        DoCmd.Close acForm, "frmLogin"
        DoCmd.OpenForm "frmMain"
    Else
        MsgBox "Invalid credentials.", vbExclamation
    End If

    rs.Close
End Sub

What this gives you: custom role-based access within your application. You control exactly which forms and features each role can access. Similar to workgroup security in terms of user experience.

What this doesn't give you: true data-level security. A user who bypasses your login form (by holding Shift at open, for example) can access all objects directly. Lock down the Shift bypass: CurrentDb.Properties("AllowBypassKey") = False

This is the most common replacement for workgroup security in converted .accdb databases.

Option 4: Hybrid with SQL Server Security (Enterprise-Grade)

For databases that genuinely require enterprise-grade multi-user security, the right path is moving data to SQL Server and using SQL Server's security model — Windows Integrated Security or SQL Server logins with role-based permissions at the schema level.

Your Access .accdb front-end connects via ODBC. SQL Server enforces row-level and table-level permissions per user. Access can't bypass SQL Server security regardless of whether the Shift key is held.

This is the right answer if your database stores sensitive data and workgroup security was the only thing preventing unauthorized data access.

Migration Checklist for Databases with Workgroup Security

Document existing permissions — before conversion, run the User-Level Security Wizard report in Access 2003 to export a complete list of users, groups, and their permissions on each object. This is your reference for rebuilding access control.
Identify which users need which access — map the workgroup security roles to your new model (read-only, data entry, admin)
Convert to .accdb — LegacyLeaps handles the conversion and VBA updates
Implement replacement security — choose one of the four options above based on your requirements
Disable the Shift bypass — if using VBA form-based security, lock down the Shift key bypass
Test each user role — verify that each role has exactly the access it should

Planning an Access migration?

LegacyLeaps handles the .mdb to .accdb conversion — VBA updates, Jet SQL compatibility fixes, linked table refresh. The free scan tells you exactly what you're working with before you start.

Try the Free Scan