NSF protection is more layered than a single password, so removing it correctly means understanding which layer is in play, since they are removed differently and one is not really removable at all without the right credentials:
The local database access, the common case: an NSF can have a local access password or be governed by the Notes ID that created it, prompting for the Notes ID password to open. This is access tied to the Notes ID, and the proper removal is through Notes itself with the authorized ID, opening the database and changing its access control or local security settings, File, Application, Properties and the encryption settings, to remove local encryption, which requires being able to open it first with the legitimate ID.
The local encryption layer, the important distinction: an NSF can be locally encrypted with the Notes ID, meaning the file is genuinely encrypted and only that ID can decrypt it and this is real cryptography rather than a removable flag. Removing it means opening the database with the correct ID and re saving without local encryption, File, Application, Properties, Encryption Settings, choosing no encryption. Without the correct Notes ID, a genuinely locally encrypted NSF is cryptographically protected and not removable, the honest boundary.
The proper procedure for an authorized user: with the correct Notes ID that has access, open the NSF and to make it freely accessible, change its encryption settings to remove local encryption and adjust the access control list, then the file opens without the ID prompt for conversion and archiving. This is the legitimate path, using the authorized credentials to remove protection from files you own, rather than circumventing protection you lack the credentials for.
The conversion angle, since that is often the real goal: many NSF converters accept the Notes ID and its password as input to read protected files during conversion, so rather than removing protection first, supplying the ID to the converter handles authorized encrypted files in one step, the practical route when the goal is conversion rather than a permanently unprotected NSF. Encrypted mail within the NSF still needs the specific ID that encrypted it, the same caveat that runs through all NSF work.