Actually, I disagree with nogdog. At least my personal implementation of user levels has been 0 = inactive 1-9 = user levels as defined by the app
So, let's say you create a new account, and set its status to 0 initially pending confirmation. Now when whatever process is followed in order to activate the account, how do you know what access value to set it to now? If it will be "obvious" for whatever reason (e.g. a small number of users and all the changes are being done manually), then fine, I suppose, but it still feels to me like two different things: you can be an active admin user or an inactive admin user; or you can be an active regular user or inactive regular user; etc. While the system can grow to have n number of user types, the active/inactive status will likely remain a simple either/or choice. If you want it to be completely automated while only using one field, you'd probably need two separate values for each user type, e.g. 0 = regular/inactive, 1 = regular/active, 2 = moderator/inactive, 3 = moderator/active, 4 = admin/inactive, 5 = admin/active, etc....
(Actually, last time I did something like this, "activation" was not Boolean, but was a timestamp; so Null for that field indicated inactive while a non-null timestamp indicated active while also providing a bit of tracking info of a sort.)