A new user is registered. In her registration pack, along with her new username, e-mail address and so on is her initial password.
Several things need to be taken into consideration here.
Firstly, how are the username and password transferred to the user? Is it passed along on hardcopy, or does it go to an intermediary (i.e.: Supervisor or Admin Assistant) via electronic means? If the former, it should be kept in a sealed, opaque, tamper-evident package from the sysadmin to the user. If the latter, the sysadmin should relay the information via encrypted e-mail to the intermediary who then uses a secure package (as described earlier) to transfer it to the user. However, it is preferable that there be no third parties involved in this transaction - ideally, only the sysadmin and the user should have knowledge of or access to the first-time password. More preferable would be that only the user has it, but this is not possible in some scenarios - such as for domain or e-mail accounts.
Second, first-time passwords should always be unique and not determinable by any information unique to the user. The best way to ensure this is to use a random password generation tool, and do not reuse the generated passwords between users. Ideally, the username should have no relation to any personally identifiable information either.
Third, the mechanism for ensuring first-time passwords are changed is very dependent upon the environment that the account is created in. Many systems have an option that can be set on accounts to force the user to change the password upon their next login. If that is available, it is the most effective means and should be used. For systems without such a feature, you are left very dependent upon the user to conform to company policy. This can be helped along by including a clear and prominent advisory about changing the password in the registration pack. Also, using a very long and complex (around 20+ random characters using all available character types should do) first-time password will naturally make the user more inclined to change it.
Lastly, if you are taking appropriate measures as specified above, auditing password changes may be difficult. If you're using a password cracking tool such as Ophcrack or LophtCrack to check this, you will have to add every individual's first-time password to the rainbow table as they are created. Some systems include the ability to check the user's password age and last login time - these can be checked against the account's creation date and the user's start date to see if the user changed it on first login. Aside from those methods, the high security of the techniques described above makes verifying first-time password changes almost as difficult as exploiting the first-time password itself.
A new piece of hardware is deployed. In its factory state it has a default admin password so you can go in and configure the hardware.
There are a few measures to be taken here, which can make the first-time password more secure and help facilitate and verify their change.
The first piece comes in materials acquisition. Try to only purchase hardware which:
Does not have a first-time password, and will not operate until the sysadmin has configured a password.
If it has a first-time password, uses one which is uniquely generated for each device and not reused between units.
After this, the only way to ensure they are being changed is often through a hands-on audit of the system, checking to see if the first-time credentials are still valid.